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ABSTRACT 

This thesis presents extensions to an implementation of 
a kernel in a real-time distributed operating system for a 
microcomputer based multi-processor system. 

The operating system, MCORTEX, is a 2 level, 
hierarchically structured, loop free, system that permits 
logical distribution of the kernel in the address space of 
each process. The design is based on segmented address 
spaces and per process stacks. Process synchronization is 
achieved through sequencers and eventcounts. MCORTEX is 
resident in the local memory of each microcomputer but 
system data is maintained in shared global memory. 

MCORTEX has been extended to include a system monitor 
process which allows stopping the system to examine any 
memory, shared or local, from any location. The system can 
then be restarted without reinitializing each microcomputer. 

This system particularly supports applications where 
jobs are partitioned into a set of multiple interacting 
asynchronous processes. The system is currently implemented 
on INTEL 86/12A single-board computers. 
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I. INTRODUCTION 



A. GENERAL DISCUSSION 

This thesis presents extensions to an implementation of 
a kernel in a real-time distributed operating system for a 
microcomputer based multi-processor system, called MCORTEX. 

As the performance and capabilities of micro-computers 
continues to improve, it is becoming apparent that many 
large real-time applications that are managed by large fast 
mini -computer s could be managed by an integrated multi- 
processor system of less expensive, commercially-available 
micro-computers. What a single general purpose micro- 
computer might lack in speed could be compensated for by a 
system of computers if it is managed by an operating system 
that allows process synchronization and parallel or 
concurrent processing. 

There are multi-microcomputer systems already in use 
today in real-time applications. However, in order to 
accommodate high data input rates and the addition of more 
processors to the system, custom interconnections often have 
to be devised so that system performance is not degraded. 
These custom designs may increase the cost of the system and 
reduce flexibility in meeting the needs of a variety of 
applications . 
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The purpose of this thesis is to continue development of 
an operating system design that is simple, small, and 
flexible. A principal goal is to demonstrate the operating 
system on commercially available, relatively inexpensive 
general purpose micro-computers requiring the minimum of 
custom-developed hardware for processor inter-communication 
and control. It is anticipated that the design will be 
general in nature in order to be applied towards various 
real-time applications and implemented on different micro- 
computer systems with the minimum of modification. The 
specific goals of this thesis are discussed in the next 
section concerning the background of the project. 

B. BACKGROUND 

The AEGIS weapons system simulation project currently 
being conducted at the Naval Postgraduate School is 
attempting to determine the feasibility of raplacing much of 
the larger and relatively expensive mainframe computer, the 
AN/UYK-7, with a system of 16 or 32 bit micro computers. 
Several significant real-time functions of the AEGIS Weapons 
System are to be duplicated with associated data, inputs, 
timing, and supporting functions so that a test example can 
be examined whose performance emulates that of the actual 
system . 

In particular, emulation of the SPY-1A radar, which is a 
sub-system of AEGIS, is being examined. Signal processing 



for long distance low altitude missile detection and target 
acquisition for tactical missiles requires processing large 
amounts of collected data in real-time. It is proposed that 
a system of micro-computers as described above could provide 
the processing power required to perform concurrent 
asynchronous computations. 

Design of the operating system that would manage such 
micro-computer system was started by Wasson who defined the 
detailed design of an operating system tailored to real-time 
image processing[Ref . 10]. He based his design on a more 
general model developed by O’Connel and Richardson of the 
Naval Postgraduate School in 1979- The design was to be 
applied to the general purpose INTEL iSBC 86/12A micro- 
computer. This single board micro-computer is based on the 
16 bit INTEL 8086 microprocessor. Wasson's design used the 
MULTICS concepts of segmentation and per process stacks and 
Reed and Kanodia's enventcount synchronization methods .[ Ref . 
9: pp. 12-13J Rapantzikos began the implementation of 
Wasson's design[Ref. 11]. 

The operating system, MCORTEX, at this point used the 
concept of a "two level traffic controller" to accomplish 
processor multiplexing among a greater number of eligible 



processes . 


This 


dual-level 


"processor 


multiplexing design" 


allowed the 


system 


to treat 


the 


two 


primary 


scheduling 


decisions , 


viz . , 


the scheduling 


of 


processes 


and the 
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management of processors, at two separate levels of 
abstraction . 

Cox continued the implementation effort of Rapantzikos 
by greatly simplifying the design of MCORTEX. He placed a 
higher priority on shortening the execution time in MCORTEX 
over the possible added security of a two level traffic 
controller and therefore, reduced the traffic controller to 
one level of abstraction which simplified the 
implementation. His other contribution was to add a 
gatekeeper module to the top of the operating system so that 
operating system calls were made through a single "gate" and 
so that the user would not have to concern himself with 
service codes. The result was a very compact, trimmed down, 
basic operating system which supports multiprocessors 
performing multiprocessing. [Ref. 12: pp. 13-14] Cox 

demonstrated MCORTEX with a system of three user processes 
executing concurrently on two INTEL iSBC86/12A 
microcomputers connected by the INTEL MULTIBUS. 

The specific goals of this thesis are to: 

1. Test the generality of MCORTEX by expanding the 
system to several additional micro-computers. 

2. Expand the system to the extent necessary to 
provide a means of dynamically interacting with the 
operating system while it is executing so that efficient 
testing of the multiprocessor system can be accomplished. 
Previously, MCORTEX had to be allowed to "run its course" 
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before examining various structures in system memory. It 
then had to be completely reloaded and reinitialized to 
resume execution. 

C. STRUCTURE OF THE THESIS 

Chapter I presents a general discussion of the larger, 
ongoing effort of which this thesis is a part. It also 
gives a general discussion of the background work that has 
been accomplished regarding the specific topic of this 
thesis, the MCORTEX operating system. 

Chapter II addresses the overall design philosohpy of 
MCORTEX and its functional requirements. Multiple process 
communication and synchronization tasks and techniques are 
included. There is also a discussion of process 
multiplexing and other utilities support for the user. 
However, the discussion is limited, inasmuch as three prior 
theses have devoted their attention to the general design. 

Chapter III describes the hardware architecture of the 
system on which MCORTEX is demonstrated and why this 
particular micro-computer was chosen. 

As the iSBC 86/12A is a developmental system, the first 
part of Chapter IV outlines the INTEL corporation support 
systems that make the use of the iSBC 86/12A possible. 
Chapter IV then addresses the detailed design of MCORTEX. 
Testing of the previous version, explanations for the path 
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chosen to implement enhancements, problems encountered, and 
their implications are discussed. 

Chapter V summarizes the testing of the operating system 
and describes the new capabilities available to the user. 
Suggestions are also given for future research and testing. 
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II. BASIC DESIGN CONCEPTS 



A. PROCESS STRUCTURE 

Dividing a job into asynchronous parts and concurrently 
executing these parts as separate entities offers 
significant advantages if the job is continuously receiving 
input and/or processing data. In a single processor the 
benefits are mainly confined to design simplicity. However, 
in a mult i -processor system these asynchronous parts, or 
processes, are essential if the system is to take advantage 
of parallel and pipeline processing. 

There are two elements that, together, are sufficient to 
characterize a process; (1) the process address space and 
(2) its execution point. 

The address space is the set of memory locations that 
could be accessed during process execution. There exists a 
possible path to all the memory locations in that space 
during the life of the process. It is this important 
characteristic that allows the "distributed" operating 
system to be viewed as part of the address space of the 
process. The entire address space can be viewed as having 
two domains of execution, the user domain and the kernel 
domain. Entry to the kernel domain of execution is 
additionally restricted to a single entry point. 
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This enhances design and ensures a certain measure of 
security. See Fig . 1 . 




The execution point is characterized by the state of the 
machine at any particular time and consists of the contents 
of certain machine registers. 

By designing a system as a collection of cooperating 
processes, system complexity can be greatly reduced. The 
asynchronous nature of the system can be structured 
logically by representing each independent sequential task 
as a process and by providing interprocess synchronization 
and communication mechanisms to prevent race and deadlock 
situations during process interactions. 
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If the processes are confined to well-defined address 
spaces that do not overlap then they would never interfere 
with each other. Some controlled form of overlapping of 
address spaces or sharing must exist if there is to be, as a 
minimum, coordination between the processes. 

B. VIRTUAL PROCESSORS AND SCHEDULING 

A virtual processor is an abstraction. It is a data 
structure that contains all the required data that describes 
the execution point of a process at any given instant. 
There is a virtual processor for every process but only one 
real processor. Each real processor has up to a fixed 
number of virtual processors and each virtual processor has 
an "affinity" for a particular real processor. This will be 
explained later in terms of the Virtual Processor Map. 

The virtual processor also has use of the process stack 



which contains 


the 


procedure 


activation 


records and other 


necessary 


data 


for 


the execution 


of 


the process . In 


actuality 


the 


data 


structure 


that 


represents the virtual 


processor 


contains a 


pointer to 


this 


stack 


. Other data that 


represents 


the 


virtual processor 


are 


"priority" of the 



process it is executing, current state of the virtual 
processor, and any "event" the virtual processor might be 
waiting for . 

As all virtual processors have the same components, the 
data structures that represent the virtual processors form 
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an array or structure called the virtual processor map 
(VPM). The VPM is used by the scheduler to select the 
proper eligible process to be executed. After selection, 
virtual processor's stack is used to restore the real 
processor to the state when it was last executing that 
process. This selected virtual processor is now "running" 
as opposed to "waiting 1 ' or being "ready" to run. The real 
processor, which is a physical object, is always running. 
In this case the real processor is the INTEL 8086. 

It is the abstraction of the real processor that allows 
multiplexing of several processes on a single processor 
resource. The high level system calls of the operating 
system operate on these virtual processors thus making the 
design independent of the configuration of the hardware. 
Adding real processors to the system, up to the bandwidth of 
the system bus, would not affect the user except that he is 
likely to obtain increased performance. 

User services available via procedure calls through the 
gate can be regarded as an extended instruction set which is 
available to the virtual processor but not the real 
processors. Rapantzikos uses, as an example, the "Await" 
operation. It does not use real processor resources but it 
does inhibit the use of the real processor by the virtual 
processor. [Ref. 11: pp.43- 2 l4] 
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C. MULTIPLEXING 



Multiplexing could also be called multiprogramming and 
it is facilitated by the abstraction of the real processor 
described in the previous section. The execution by the 
virtual processor of a sequence of operations is actually 
performed by the real processor. However, the sequential 
operations may be separated by gaps of time when other 
virtual processors are executing a sequence of operations. 
This allows efficient use of scarce real processor 
resources. Figure 2 shows how several virtual processors 
could be mapped into the operation sequence of one real 
processor. When each virtual processor is executing on the 
real processor it said to be "bound" to the real processor. 
The length of each horizontal line represents the amount of 
time that virtual processor is bound to the real processor. 
Only one virtual processor can be running at any point in 
time. However, any number of virtual processors can be 
ready-to-be-scheduled or waiting for some other event. 
Figure 3 shows the possible state transitions of a virtual 
processor . 

For a portion of the time that a virtual processor is 
executing, it could be in the kernel domain of execution. 
This implementation uses a distributed kernel which is 
inter ruptable and loop free. Thus, the virtual processor 
can be interrupted at almost any point in time and continue 
on the next time it is scheduled. It should be noted that 
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loop free indicates a condition in which a module which uses 
part of a second module cannot in turn be used or called by 
that second module. 




Fig. 2 Multiplexing 




Fig. 3 Virtual Processor State Transitions 



Therefore, multiplexing is the means by which a system 
which has more processes than it has processors, can 
efficiently schedule those processes and make effective use 
of the real processor's time. It also makes the design and 
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implementation of the operating system easier to understand 
and document. 



D. MULTIPROCESSING 

In a multi-processor environment, concurrent processing 
is a natural byproduct. The process structure previously 
revealed is used to divide a job into separate sequential 
tasks that can now be scheduled to run concurrently. 
Although the response time for a job might not decrease, 
the throughput would increase. Therefore, significant gains 
in efficiency can be made. 

When multiplexing and multiprocessing are combined, a 
system is obtained with a significant throughput advantage 
that can react efficiently to asynchronous events. This 
implementation uses a single, system-wide, preemptive 
interrupt mechanism to signal the need for rescheduling in 
the mult i -process ing environment. Furthermore, the above 
requirements reinforce the choice of the iSBC86/12A to 
implement MCORTEX. Commercially-available , general-purpose 
hardware is available to interconnect the iSBC86/12A micro- 
computer s . 

It should be noted that in the interest of keeping 
MCORTEX small and fast, virtual processors being scheduled 
on one real processor will never be scheduled on another. 
This is a result of Cox's work in symplifying the design of 
MCORTEX. Virtual processors have an "affinity" for the real 
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processor on which they were origins 
remembered that MCORTEX is for a rea 
environment and scheduling decision 
time possible. The memory management 
be required otherwise would degrade 
real-time environment. 



lly loaded. It must be 
1-time mul ti -processor 
s must take the minimum 
functions that would 
the performance of the 



E. COMMUNICATION AND SYNCHRONIZATION 

For concurrent processing, a job that is composed of 
sequential and non-sequential tasks is explicitly divided 
into an appropriate structure of processes that can run 
concurrently. Inter-process communication and 
synchronization are necessary for concurrent processing. 

It is the responsibility of the operating system to 
provide mechanisms for effective communication between 
cooperating processes. There are two kinds of 
communications that processes must be able to achieve. 
There must exist a way for processes to exchange data. This 
is called inter-process communication. There must also exist 
a method for processes to order their execution in response 
to certain events, particularly events affecting the shared 
memory status and validity. Therefore, to utilize the 
parallelism and pipelining afforded by multiple processors, 
a mechanism is required for synchronization between 
processes. Rapantzikos [Ref. 11] made the decision to use 
the eventcounts and sequencers of Reed and Kanodia [Ref. 9]. 
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This provides automatic "broadcasting’' and supports 
"parallel signaling". Another reason eventcounts and 
sequencers were chosen is because in addition to providing 
synchronization, a history of the jobs execution is 
maintained . 

The synchronization between processes is supported by 
the "Await”, "Advance", and "Preempt" functions. Except for 
"Preempt", these functions operate on the eventcounts. The 
"Ticket" function operates on sequencers. Cox 
[Ref. 12:p.26] mentions that the "Ticket" function applied 
to sequencers supports the exclusive access of a process to 

a shared resource. It is also used to provide odered access 

< 

to the resouce on a first come, first served basis. 

The number of times an "event" has occurred is 

A V 

represented by an eventcount. Await blocks the currently 
running process until a threshold value has been reached for 
a particular eventcount. "Advance" increments the current 
value for a particular eventcount. Thus, "Await" and 
"Advance" can be used to provide cooperation between 
processes . 

"Preempt" forces the scheduling of a high priority 
process that will then block itself. This is sometimes 
required for very critical asynchronous processes. However, 
if there still exists higher priority processes that are 
ready, they will be scheduled first. 
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” Preempt 
priority 



is used sparingly and only for the very 
processes normally. 



highest 
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III. MULTIPROCESSOR ARCHITECTURE 



The micro-computer selected to initially implement 
MCORTEX is the INTEL iSBC86/12A single board computer (SBC). 
It is based on the INTEL 8086 16 bit micro-processor. 
Detailed descriptions of all the components of the SBC and 
the multiprocessor interface, the MULTIBUS, can be found in 
[Ref. 1] and [Ref. 2]. 

A. HARDWARE REQUIREMENTS 

1 . Shared Global Memory 

Shared global memory is required in this 
implementation as the means for virtual processors to 
coordinate their communication with each other. The 
operating system is resident in the local memory of each 
real processor where it is a distributed part of the address 
space of each process associated with that processor. 
However, data concerning all the virtual processors in the 
multi-processor system exists as one copy in shared global 
memory. One of the reasons for keeping all virtual 
processor data in one structure in global memory is the way 
the total structure is operated on by various MCORTEX 
synchronization system calls. Those functions as well as 
the global data base structure will be detailed in Chapter 
IV, Section C. 
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2 . Synchronization Support 



To prevent concurrency problems in the shared global 
memory, a software lock is used for access to the shared 
data base. However, the lock itself has to be protected 
from deadlock and race conditions. Therefore, an 
indivisible "test and set" mechanism is required. PL/M-36 
and ASM86 both support this protection device. In PL/M-86, 
the mechanism is the built-in procedure "Lockset" 
[Ref. 8:pp. 12-14 to 12-15]. In ASM86 support comes in the 
form of an instruction prefix "lock" [Ref. 5:p. 5-9^1 • The 
"lock" prefix, which is also used in the function "Lockset", 
causes the system bus, the MULTIBUS, to be locked during the 
duration of the following instruction. This prevents the 
interleaving of instructions and/or access by another 
processor. Therefore, only one processor can access and 
change the global lock variable at any one time if the above 
support feature is utilized. By necessary convention, it is 
the responsibility of the processor who last had access to 
the lock variable to unlock it. Processors are then assured 
of mutual exclusion while updating the shared data base. It 
is worth reiterating that the system bus is locked only 
during the testing and setting of the software lock and not 
during the software restricted access to the shared data 
base. Normal use of the system bus continues while one real 
processor is accessing that part of shared memory protected 
by the software lock. 
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3 . Inter-processor Communications 



Some method of communication between real processors 
is required if the processes they are executing are going to 
be synchronized. In the asynchronous real-time environment, 
the communication will invariably come in the form of an 
interrupt mechanism. The iSBC86/12A supports many different 
interrupt schemes. This implementation requires a single 
system interrupt that any real processor can use to 
"broadcast" an event. Every other real processor has to be 
able to recognize it and react to it. This preemptive 
interrupt signals to the other processors that a possible 
rescheduling of a virtual processor is necessary. The 
specific interrupt structure in hardware is detailed in 
this chapter in Section D. The software mechanism that 
decides which processor should react to the broadcast 
interrupt signal is detailed in Chapter IV, Section E. 

B. HARDWARE CONFIGURATION 
1 . System Configuration 

Figure 4 shows a general drawing of the multi- 
processor system configuration. The CPU's are iSBC86/12A 
single board micro-computers that come with 64K bytes of 
local memory. In Cox's work an inactive iSBC86/12A's memory 
served as the global memory module [Ref. 1 2 : p . 49 3 • The 
module was replaced in this implementation with a 32K byte 
RAM board compatible with MULTIBUS. Communication with each 
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CPU for the purpose of loading developed software is via the 
serial port on each SBC. 
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2 . The 8086 Microprocessor 



The 8086 is well-documented in [Ref. 1] and 
[Ref. 2]. This section is intended to give general 
knowledge about the 8086. 

The 8086 is a high performance, general purpose 
microprocessor. The CPU contains an Execution Unit (EU) and 
a Bus Interface Unit (BIU). The two units operate 
independently of each other. The EU executes instructions 
in much the same way as a conventional CPU. But the BIU is 
dedicated to fetching instructions, reading operands, and 
writing operands which the EU is executing or operating on 
respectively. The BIU also "pipelines" or stacks 
instructions in an internal RAM array to a level of six. 
Thus, a majority of the fetch time in executing instructions 
disappears. The number of instructions executed per unit 
time significantly increases and idle time on the bus is 
minimized . 

The 8086 has a 16 bit data path and address space of 
one megabyte. The CPU gives direct hardware support to 
programs written in the high level language, PL/M-86. Those 
very low level routines that must be written in assembly 
language are developed in ASM86. The object code modules of 
each can be linked together without difficulty. The basic 
instruction set provides for direct operations on memory, to 
include stack operands. It provides software generated 
interrupts, byte translations from one code to another, 
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move, scan, and compare operations for strings up to 64K 
bytes in length, multiplications and division of binary 
numbers . 

The 8086 has eight 16 bit general registers, four of 
which are byte addressable. The remaining four are index or 
pointer registers, which could also be utilized as 
accumulators like the first four. Figure 5 shows the 
organization of the 8086 registers and their principal use. 

The 8086 has nine status bits that can be set in the 
flag register which is a 16 bit register. The functions of 
the status and control bits are listed in Figure 5* One 
bit, the IF flag or interrupt flag, has special 
significance. If the flag is ”1" it enables maskable 
interrupts. If it is "O'* it disables maskable interrupts. 
The flag must be initialized for appropriate use in the 
operating system. The IF flag will be described in greater 
detail in a later section. 

3 • Segmentation and Segmentation Registers 

The 8086 does not support the notion of explicit 
segmentation. For example, it contains no special hardware 
to perform memory management functions, segment access 
checks, or bounds checking. However, addressing is 
"segment-like" as it is two- dimensional. All addresses are 
composed of two parts: the base and the offset. 8086 
programs view the one megabyte address space of the 8086 as 
a group of segments that are defined by the application. 
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The base is an absolute address that points to the low 
memory end of a segment aligned on 16 byte boundaries. The 
offset is a 16 bit number that indicates position from the 
base address. Therefore, any segment can be up to 64K bytes 
long and consists of contiguous memory. The segment base 
address can point to any location in the one megabyte 
address space. As the base segment address can only be 16 
bits long, the low four bits are assumed to be zero. 
Segments may overlap, partially overlap, be adjacent to each 
other, or be disjoint. 

The segment registers contain the various segment 
base addresses. At any point in time the CPU can address 
four segments. The function of the segment registers may 
sometimes alternalte but in this implementation they are 
used in their default roles. Figure 5 applies to the next 
several paragraphs. 

The code segment register (CS) contains the high 16 
bits of the absolute address of the currently executing code 
segment. The register is used in conjunction with the 
instruction pointer register (IP) which is an offset value 
from the contents of the CS register. Together, these 
registers are used in a similar manner to the program 
counter of smaller micro-processors. All instructions are 
fetched from this segment and the IP always points to the 
next instruction to be fetched. 
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The data segment register (DS) contains the starting 
address of the current data segment and generally contains 
program constants and strings. It is routinely used in 
conjunction with the source index register (SI) and the 
destination index register (DI). The DS register may be 
changed during execution of the program and, normally, each 
code segment will have an accompanying data segment. 

The stack segment register (SS) is used to implement 
the per process stacks required by MCORTEX. It is used in 
conjunction with the stack pointer register (SP) and the 
base pointer register (BP). Rapantzikos had two stacks in 
effect at any one time in his implementation, a kernel stack 
and a user stack [Ref. 1 1 : p . 7 4 ] . When Cox simplified 
MCORTEX, only one stack remained. As MCORTEX can be viewed 
as part of the process address space, there is only a need 
for a per process stack. The contents of the SP register 
indicate an offset in higher memory from the SS register 
contents. SP points at the current top of the stack which 
grows towards lower memory and the stack base. Therefore, 
the initial value of SP indicates the bottom of the stack. 
BP is kind of a utility marker. The first time it is used, 
it points to the same location as SP at the beginning of the 
stack. If for some reason, a group of arguments are pushed 
on the stack (as in preparation for a procedure call), the 
BP contents are pushed on the stack and then BP is updated 
to equal the current SP (top of the stack). In this way, an 
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activation record is delineated. When it comes time to 
discard the arguments, the CPU knows how far back down the 
stack to go. (In actuality, the SP is updated with the BP 
value on top of the stack. Nothing is ever erased from the 
stack. SP and BP are simply constantly manipulated. Growth 
of the stack will overwrite some locations.) Stacks can be 
up to 64K bytes long and, like all other segments, can be 
placed anywhere in the one megabyte address space. 

The extra segment register (ES) is typically used 
for external or shared data, and data storage. 

4 . The iSBC86/ 12A( Single Board Computer) 

The iSBC86/12A is a complete computer capable of 
stand-alone operation. It is used as the basic processing 
node of this multiprocessor system. The SBC includes the 16 
bit 8086 CPU, 64K bytes of RAM, a serial communications 
hK9terface, three programmable parallel I/O ports, 
programmable timers, a programmable interrupt controller, 
MULTIBUS interface logic, and bus expansion driver for 
interface with other MULTIBUS compatible expansion boards. 
There are provisions for the installation of up to 16K bytes 
of ROM. As MCORTEX progresses it is anticipated that the 
operating system will be programmed into ROM. 

There are three sets of connections that must be 
made to each SBC. By convention one single board computer, 
SBC #1, has been selected to provide the MULTIBUS clock 
signal. Switches and jumpers for extended addressing must 
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be set and there are three jumpers used to implement the 
preemptive interrupt system. The system bus clock is 
provided by jumping the adjacent pins E 1 0 5 and E 1 0 6 on SBC#1 
ONLY. The latter two sets of connections are explained in 
the next two sections. 



C. PHYSICAL ADDRESS GENERATION 

1 . General 

There are two methods to specify a memory address. One 
is the absolute or physical address and the other is the 
logical address. There is only one physical address that 
will specify a given memory location but there may be 
several logical addresses equivalent to one absolute 
address. Absolute addresses can range from 0 to FFFFFH. 
The following are two examples of how the processor 
reconstructs absolute addresses from two-dimensional logical 
addresses : 

a. 1234:0000 b. 1200:0340 

It should be noted that the base and offset are held in 
separate 16 bit registers. The base in both examples is 
shifted left four bits and then the offset is added. A 20 
bit address results which ranges the entire one megabyte 
address space. 



a. 1234 
1 2 3 4 0 < 
+0000 



b. 1200 
1 2000< 
+0340 



12340 12340 

The shifting of the base is what forces the alignment of 
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segments on 16 byte boundaries. It is apparent that the two 
different logical addresses are equal to the same absolute 
address. The above is an extended address because it falls 
outside the range 0 to FFFFH or 64K byte range of a single 
processor. Which processor the reference is made to is 
discussed in the next section. 

2 . Local and Extended Addresses 

Addresses outside the range o to FFFFH are extended 
addresses from the point of view of a single board computer. 
As the other SBC’s also have 64K bytes of local RAM, there 
must be some way of designating where in the one-megabyte 
address space they fall. Locally, the SBC does not need or 
recognize the 20 bit address. If one is specified, the SBC 
has to know, via the MULTIBUS, where to go. The iBSC86/12A 
contains jumpers and switches that allow it to translate 20 
bit addresses into local memory. If each SBC is configured 
properly, each 64K byte local RAM could be given a unique 
identity in the one- megabyte address space as viewed from 
the MULTIBUS. Those connections are listed in the next 
section. Understanding how local and extended addressing 
works, and how absolute addresses are formed from two- 
dimensional addresses is important because the 
implementation of MCORTEX on the ISBC86/12A depends on it. 
The next several paragraphs assume that the SBC's have been 
configured as listed above and that the full 64K bytes of 
RAM is visible or accessible from the MULTIBUS. 
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From the point of view of the monitor currently 
resident in ROM on the SBC, the designer can specify 

absolute or two-dimension addresses. For example, the 
display command, "D", can be executed by typing: 

a. .D2345 or b. .D0200:03^5 

The many ways Example (b) could be listed have already been 
explained in Section A. Example (a) will return the same 
result. The difference is noted in how the CS and IP 

registers will be loaded to fetch the contents at that 
location which, incidentally is in local memory. If Example 
(a) had been a number greater than FFFFH , the address would 
have been "wrapped around" to lower memory. For example: 

. D 1 2345 

would have returned the contents at 23^5H, as that was 

loaded into the SI. DS was assumed to be zero. However, an 

example such as : 

. D 1 200 : 0345 

would have returned the contents at 1 2 3 ^ 5 H , which is 
external to the local memory. In this implementation, the 
address would have been on SEC #1 at its local absolute 
address of 23^5H. SBC # 1 as viewed from the MULTIBUS, has 
all of the memory from 10C00H to 1FFFFH. A full listing of 
these translations will be given in the next section. 

From the point of view of the HOL, PL/M-86, 

knowledge of local extended addressing is also important. 
The compiler represents pointer values differently depending 
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on options set at compile time. All code compiled for 
MCORTEX and the user processes must be done with the 
attribute "LARGE''. For example: 

: F 1 : PLM86 PR0CESS5 • SRC LARGE 

will result in the PLM source file " PR0CES5 • SRC" to be 
compiled. The attribute "LARGE" indicates to the compiler 
that references outside the 64K byte range of local memory 
are to be made, and therefore, address references have to be 
represented in a certain way. Specifically, pointer 
variables can now have the value 0 to FFFFFH and even if the 
source code contains an absolute reference, it will be 
represented in memory as two words. The higher two bytes 
will contain a base value from 0 to FFFFH and the lower two 
bytes will contain an offset value from 0 to FFFFH. For 
both the offset and base the least significant 8 bits are in 
the first byte and the most significant 8 bits are in the 
second byte. This knowledge was used to implement the 
diagnostic monitor process so that it could access any 
memory from any SBC in the multi-processor system. 
[Ref. 6 : pp . B- 1 to B-8] [Ref. 7:p.5-4 and 8-1] [Ref. 8:p.4- 
14 and 8-3] 

The locator, "L0C86", also makes use of local and 
extended addresses. The locator takes an object module that 
has been linked with necessary modules and resolves all 
relative referances into actual addresses. To maintain the 
integrity of modules during testing and because it is 
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necessary to overlay some modules on top of each other, 
certain segments are "located" at specific addresses. The 
following example comes from the locate command file 
actually used to locate the operating system whose file name 
is "KORE.LNK": 

L0C86 KORE.LNK ADDRESSES(SEGMENTS(& 

STACK ( 03000H ) ,& 

INITMOD_CODE(02800H) ,& 

GLOBALMODULE_DATA( 0E0000H) ) )& 

SEGSIZE(STACK(75H) )& 

RS( OH TO OFFFH) 

Absolute addresses have been specified for two modules and a 
stack segment. All will be located at local addresses 
except for the global data base. An external 32K RAM board 
has been attached to the MULTIBUS to serve as global memory. 
It will recognize references from the MULTIBUS from E0000H 
to E7FFFH. The output of this command is the executable 
code module, KORE, that could then be loaded on all the 
SBC's. Each SBC would have a copy of MCORTEX in its local 
memory and each would "know" where to go to find the global 
data base. 

3 • Hardware Connections for Local/Extended Addressing 
The following are the hardware connections needed to 
set up RAM addresses properly for MULTIBUS interface access. 
They consist of one jumper connection and eight switch 
settings on a dual-inline package (DIP) called SI. Each 
board's full 64K byte RAM is made accessible to the MULTIBUS 
by setting switches #5 and # 6 open on every SBC. Switch #8 
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on SI is always open. Switches 1-4 have to do with 
displacement of the base address as seen from the MULTIBUS. 
It is necessary to only use switch #1 to indicate a 64K 
displacement from the top of a selected 128K byte segment in 
the one-megabyte address space. Switches 3-4 are always 
open. The jumpers select the 128K byte segment of the one- 
megabyte address space where the 64K byte RAM will be 
placed. [Ref. 2:pp.2-7 to 2-9] 



Table 1. RAM ADDRESSES( MULTIBUS INTERFACE ACCESS) 



SBC // 


Switch //I 


Jumper Connections 


Placement 


0 


closed 


127-128 


00000H-0FFFFH 


1 


open 


127-128 


1000CH-1FFFFH 


2 


closed 


125-126 


20000H-2FFFFH 


3 


open 


125-126 


30000H-3FFFFH 


4 


closed 


123-124 


40000H-4FFFFH 


5 


open 


123-124 


50000H-5FFFFH 


6 


closed 


121-122 


60000H-5FFFFH 


7 


open 


121-122 


70C00H-7FFFFH 


8 


closed 


119-120 


80000H-8FFFFH 


9 


open 


119-120 


90000H-9FFFFH 



D. INTERRUPT HARDWARE 
1 . Description 

As with most other micro-processors, the 8086 does 
not possess the capability to directly generate interrupts 
destined for other devices. This characteristic is needed 
to implement preemptive scheduling. One of the high bits 
from one of the parallel ports is used to initiate the 
interrupt. The MULTIBUS has eight interrupt request lines 
that can be used, INTRO through INTR7- INTR4 was arbitrarily 
selected. The output bit from the parallel port must drive 
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the interrupt request line and it must follow convention by 
using a negative-going-signal on the MULTIBUS interrupt 
request line to request interrupt service. A single input 
nand gate serves to drive and invert the signal onto the 
MULTIBUS. Likewise, the same interrupt request line must be 
connected to the programmable interrupt controller (PIC) 
which recognizes a positive or positive-going-signal to 
initiate an interrupt sequence with the CPU. By using the 
single INTR4 line, all SBC's react to the interrupt signal 
when one board issues it (as well as the one that issued 
it.) This does not create a problem and it will be 
explained in the next chapter. In summary, the high bit 
from a parrallel port is used to broadcast an interrupt 
signal onto the MULTIBUS INTR4 line which is in turn 
connected to the PIC. 

2 . Hardware Connections 

Figure 6 shows three connections that must be made: 

E9 to E 1 3 

E69 to E77 

El 37 to E 1 42 

More detailed drawings are contained in [Ref. 2:pp.5- 
21 to 5-24]. 
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IV. DETAILED SYSTEM DESIGN AMD IMPLEMENTATION 



A. STRUCTURE OF THE OPERATING SYSTEM 

The distributed modules of the operating system create a 
virtual machine hierarchy which controls process 
interactions and manages real processor resources. The 
operating system is not aware of the details of process 
tasks. It knows each process only as an entry in the 
virtual process map. It provides processes with scheduling, 
synchronization, input/output services, and a diagnostic 
process . 

The operating system is constructed in terms of four 
layers of abstraction. Each layer, or level, builds upon 
the resources created at lower levels (See Figure 7)* 

Level 0 is the bare machine which provides the physical 
resources, real processors and storage, upon which the 
virtual machine is constructed. 

Level I is the scheduler and operating system support 
functions. This is the first layer of the software. It is 
closest to the hardware and encompasses the major machine 
dependent aspects of the system. Since several of its 
functions are directly involved with the hardware, it was 
necessary to code some of it in assembly language. This 
section also contains the "starting point of the operating 
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system" and a small section of code to initialize physical 
devices . 

Level II is the utilities/services level. All user 
available services are located here. Input functions were 
added and the "Preempt" function was corrected and changed 
to reflect the addition of a new system process. 

Level III is the supervisor. It is essentially, the 
Gatekeeper module of Appendix I, and provides parameter 
adjustments for services requested by the user and a single 
entry point link to the operating system "Gatekeeper" in 
Level II. 

Three system processes are "given" to the user. They 
are system processes as opposed to user processes because 
they are created by the operating system. The initial 
process, the idle process, and the new monitor process are 
scheduled by the same rules as any user process. 

B. SYSTEM DATA BASE 

A software lock is provided for the global data base 
used by the operating system. It is called "GLOBAL$LOCK" . 
It has nothing to do with any shared data structures in 
global memory set up by user processes, but only the system 
data base, which is resident in shared global memory. 
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1 . Virtual Processor Map 



The Virtual Processor Map (VPM) is the major data 
base on which scheduling decisions are based. The table is 
partitioned into sets of virtual processors. There is one 
entry in the table for each virtual processor in the system 
and one virtual processor for each process if it has ever 
been created. Currently, the table is set to handle ten 
virtual processors for each real processor. In addition, 
the table can handle ten real processors. Three process 
entries occur by default for the idle, initial, and monitor 
processes. These processes are created and initialized by 
the operating system. A real processor will have ten 
contiguous entries in the VPM, seven of which are available 
to the user. As the VPM is an array of records, the index 
to each record or virtual processor structure is, in effect, 
a unique system ID for the virtual processor. Each entry 
consists of: a process ID given by the user, current state 
of the process, process priority, an eventcount thread, the 
threshold value for the event it is waiting for, and the 
stack segment base address for the process. The virtual 
process ID of FFH and FEH are reserved for the operating 
system. FFH is used by the idle process and the initial 
process. FEH is the unique identifier for the monitor 
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2. Eventcount Table 



The eventcount table is for synchronization. It is 
an array set up for 100 possible entries consisting of an 
event name, current value, and an eventcount thread. 
Associated with each entry is an index. Each eventcount 
thread is the start of a blocked linked list. If the thread 
value is FFH, then that is the end of the list. Otherwise, 
is equal to some index value in the VPM. That VPM entry, or 
virtual process, will be active and waiting for a certain 
threshold value for that eventcount. The VPM entry may 
itself contain another thread value indicating that some 
other virtual process is waiting on the same event. 
However, it could be a different threshold value. 
Associated with this eventcount array is the variable 
"Events" which indicates how many active events there are 
currently in the table. 

One event name, FEH, is reserved for the operating 
system. It is used to block processes that will never be 
awakened by the normal "Advance" mechanism. The initial 
process and monitor process are examples. See any INIT 
module in the appendicies. 

3 . Sequencer Table 

The Sequencer Table is used to support process 
synchronization and ordering. Space is reserved for 100 
sequencers. Each entry consists of a sequencer name and a 
value. Associated with the table is the variable 
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"SEQUENCERS" which indicates the number of active entries in 



the table. 

4 • Other System Data 

Another structure in shared global memory is the 
Hardware Interrupt Flag array. There is one flag for every 
real processor, so the maximum size of the array is ten. 
The index of the array corresponds to the system unique CPU 
number for each real processor that is maintained in each 
local memory. 

There are two utility variables kept in the system 
data base; (1)the number of active real processors, and (2) 
an array that keeps track of the number of virtual 
processors active on each real processor. The index of the 
array corresponds to the system unique CPU number for each 
real processor. 

"CPU$INIT" is a byte variable that is accessed and 
incremented once each time a real processor becomes active. 
It is used to establish the system unique CPU number that is 
the key to the way all of the information in the system data 
base is organized. The reason this method is used, as 
opposed to the "Ticket" operation, is to preserve the 
hierarchy of the operating system. 
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C. LOCAL DATA BASE 



The local data base for the operating system is the 
Processor Data Segment (PRDS). It contains information that 
applies only to the real processor on which it is resident. 
It consists of the system unique CPU number, the index of 
first entry in the VPM for that real processor, the index of 
the last possible entry in the VPM for that real processor, 
a counter that reflects the relative amount of time spent in 
the idle process, and a redundant variable that reflects the 
number of virtual processors currently assigned to the real 
processor. This number is maintained in shared memory and 
it is derivable from the second and third items in the PRDS. 

D. INTERRUPT STRUCTURE 

The operating system controls the multiprocessor 
environment. A means of communication or signaling between 
real processors is required. A single, system-wide 
preemptive interrupt signal is the vehicle to accomplish 
this. It was arbitrarily chosen to be interrupt-request-4 
of the eight available for use. The hardware connections 
required to implement the system interrupt are described in 
detail in Chapter III, Section D. Software control is 
required to ensure that the hardware performs with certain 
characteristics and to actually issue the interrupt. 
Several problems were encountered in the testing of this 
part of the system. 
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A brief description of the entire interrupt sequence is 
in order first. The operating system finds, in the course 
of events, that one or more processes are waiting for an 
event that the currently running process just caused. If 
any of those waiting processes are associated with the same 
real processor, then the scheduler will simply be called to 
make a scheduling decision. If those waiting processes are 
associated with other real processors, then the operating 
system has three things to do: (1) It locates the waiting 
processes in the VPM and changes their state to "ready", (2) 
It sets the hardware interrupt flag associated with each 
real processor, and (3) it issues the single system wide 
interrupt signal to indicate to all processors that a 
scheduling may be in order. All processors will execute 
their interrupt handler which in turn will check to see if 
their respective flags are set. If the flag is set, a call 
to the scheduler is made. If it isn't, normal execution 
resumes. The adopted convention in this implementation is 
that the processor issuing the interrupt never sets its own 
flag. If it needs rescheduling, the scheduler is called 
directly . 

At this point it would be good to review Figure 2 in 
Chapter III, Section D. Note the positions of the interrupt 
driver and the other inverter. There is also a pull-up 
resistor on the INTR4 line on the MULTIBUS side of the 
interrupt driver. More complete coverage of the hardware 



51 



devices and their programming is given in [Ref. 3-PP*B- 
106 to B-123] and [Ref. 3-PP-A-136 to A— 1 36] for the PIC. 
The best reference for the PPI is [Ref. 2]. 

All of the initialization software for the PPI and PIC 
is correct. It will be explained at the end of this 
section. However, the misunderstanding of one of those 
programmed features caused the poor design of a very small 
but critical portion of the operating system. There are two 
procedures that issue interrupts, "Preempt" and "Advance". 
Cox arranged the instructions for issuance of the interrupt 
in the following manner: 

OUTPUTC P0RT$CC) = RESET; 

OUTPUTC P0RT$CC) = 80H ; 

In one procedure interrupts were disabled during this 
sequence and in the other they were not. Now they are both 
disabl.ed consistently. The above sequence is not logical 
because the INTR4 line on the MULTIBUS is not reset after 
being used. Thus, no one else can use it. Other processors 
would not have their interrupts recognized unless the 
original processor that sent an interrupt, reset it. They 
could send it, but it would have no effect on a MULTIBUS 
interrupt line already being held low. That could have 
disasterous consequences. Cox's demonstration of two 
processors with three processes worked by accident. The 
sequence was the only way he could get the other processors 
to recognize an interrupt signal. Supposedly both 
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processors were issuing interrupts, when in fact only one 
was. The demonstration appeared to work because of timing. 
An interrupt signal causes all processors to check the 
hardware interrupt flags. Therefore, even if an interrupt 
signal was missed, the hardware interrupt flag was at least 
set. If the one processor that had control of the interrupt 
request line could issue another interrupt, then 
rescheduling would occur none the less. Additionally, the 
controlling process in Cox's demonstration was ten times as 
long as the other two combined on the other processor. This 
combination of features allowed the system to synchronize. 
The moment additional SBC's were added to the system or the 
system was loaded down with more processes, it failed to 
synchronize and the entire system would idle. 

The first step in solving the interrupt problem was to 
reverse the two instructions because that was a requirement 
for the system to operate asynchronously. Diagnostic 
hardware was used to determine why no interrupts were 
recognized from this "correct" sequence. It was found that 
although the PIC was programmed to be edge triggered, the 
active level had to be maintained for a short period before 
the interrupt request was recognized by the CPU. In the 
corrected sequence, the interrupt request was apparently 
being removed or reset too quickly. After arbitrarily 
introducing a delay, all other CPU's recognized the 
request. It is suggested that an interrupt acknowledge 
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system of flags be set up so the interrupting CPU will have 
a positive indication that interrupted processors reacted to 
the signal. 

In testing the generality of MCORTEX once the interrupt 
problem was tentatively cleared up, additional SBC's were 
added to the system. It was found that an uninitialized SBC 
would hold down the IMTR4 line. This will kill all 
communications between processors. If the additional SBC's 
were loaded with MCORTEX and no user processes, then the 
system communicated effectively because the operating system 
would initialize the PIC's and PPI's. This is the reason in 
Appendix A that any SBC with no user process, "idle CPU's", 
are initialized first. 

MCORTEX has now been tested with four SBC's. One SBC 
was maintained as an "idle CPU". Three were loaded with 
five processes. The original three processes of Cox with 
slight changes were kept. Then an independent system of two 
processes was added. The two independent systems share one 
of the SBC's. In addition, the new system actually 
demonstrated the sharing and passing of information via 
common memory. Prior demonstrations only tested 
syncrhoni zation . To prevent the system from scheduling 
processes in a repeated sequence, input was prompted from a 
user. This new demonstration showed truly asynchronous 
processes working together and interfering with each other. 
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However, this demonstration does not guarantee the correct 
operation of the preemptive interrupt. 

A final point needs to be emphasized at this point. The 
question has been asked, "Will interrupt requests from 
different processors ever overlap?" The answer is no. They 
are guaranteed mutual exclusion because the system data 
structures are locked before the interrupt request is 
issued. No other single board computer can issue an 
interrupt until it controls the lock. 

To implement the interrupt structure, the PIC and PPI 
have to be initialized. The triggering mode, interrupt 
vector table address, and the parallel port mode have to be 
set. The type (number) of interrupt received is added to 
the interrupt vector table control word and multiplied by 4. 
The result points to a 2-word (4-byte) memory space in the 
interrupt vector table — called the interrupt vector. The 
interrupt vector points to the address of the intended 
interrupt handling procedure. The interrupt vector consists 
of the offset and code segment base address for the 
interrupt handler. An interrupt will cause the flag 
register, CS register, and the IP register to be pushed onto 
the stack. Then, an indirect call is made through the 
interrupt vector to the interrupt handler. 

Initialization of the 8259 PIC must follow a specific 
format and sequence. It can require up to four interrupt 
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control words (IWC) for initialization . In our case, only 
three are required: IWC1, IWC2, and IWC4. 

IWC1 must go to port OCOH. It is 1 3H . It means edge 
triggering, no slave PIC’s, and IWC3 is not required. 

IWC2 must go to port 0C2H. It is 40H. It indicates 
that the interrupt vector table starts at 40H x 4 which is 
100H. IWC4 must go to port 0C2H. It is OFH. It indicates 
8086 mode, automatic end of interrupt, and buffered mode. 

The result of the initialization is that in the case of 
an INTR4, the PIC will perform the following operation: 

4x ( IWC2+INTR# ) r 4x ( 40H + 4 ) = 1 1 OH 
The result is that the interrupt vector address for an INTR4 
is 110H. The two words residing at 1 1 OH and 112H will be 

used for an indirect call to the INTR4 interrupt handler: 

[ 1 10H] : [ 1 12H] 

The starting address of the interrupt handler must be loaded 
to this vector address. 

There are three parallel I/O ports. One bit of one of 
the ports is used to drive the INTR4 line. Port C and bit 7 
are used. See Figure 2 for details on connections. One 
control word is sent to port OCEH to indicate that port C 
will be used as an output port. The control word is 80H. 
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E. PROCESS STACK 



The per-process stack is used to form a virtual 
processor which maintains the process state information. 
This includes the current execution point, the code and data 
segment base addresses, and in a particular instance, all 
the working registers. Since this stack reflects the state 
of the real processor registers at the time of execution, 
this data structure represents a virtualization of the real 
processor. By loading the stack segment base location into 
the SS and restoring the real processor status from the 
stack contents, the process execution can be continued where 
it last left off. To change processes, the real processor 
status is saved on the current process' stack for future use 
and the new process' stack segment is loaded into SS from 
the VPM. The real processor status is then restored from 
this new stack segment. 

A three word header is maintained at the stack segment 
base: stack pointer (SP), base pointer (BP), and 
interrupt-return-type (INTR$RET). This header is used to 
make the proper adjustments and decisions for restoring the 
hardware condition during scheduling. 

Each process must have its own unique stack. The per- 
process-stack is automatically blocked out approximately 125 
words of user run-time stack. 
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F. SCHEDULING 



The scheduler has two different entry points and two 
different exit points. The difference exists because of the 
different requirements for saving registers. 

A normal entry call by a Level II function does not 
require any general registers to be saved. The only 
register which must be explicitly saved on the stack is the 
data segment register (DS). At this time, INTR$RET is set 
to ”0", indicating a normal scheduler call. The scheduler 
executes and process selection and initiation take place. 

An interrupt entry call is made through the interrupt 
handler which checks the hardware interrupt flags to see if 
it is the one for which the interrupt is intended. If so, 
all registers are saved in a particular order. INTR$RET is 
set to 77H, indicating an interrupt scheduler call. As DS 
was already saved, the scheduler is entered at a different 
point to avoid that instruction. Process selection and 
initiation then take place. 

In the common code, the past process' stack status is 
saved in the stack heading. Also, the return type indicator 
is saved in the stack header to be used when the process is 
ever rescheduled. "Getwork" is called to select the highest 
priority process that is ready to run. The stack segment 
for the selected process is returned in AX. "Getwork" 
received the information from the VPM. The scheduler loads 
AX into the stack segment register. The context has 
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effectively been switched. The new process' stack condition 
is restored and the return type indicator is checked to 
ascertain the circumstances of the process' last run-time 
termination. If the indication is a normal return, DS is 
restored and the process returns to its calling point. If 
the indication is an interrupt return, then all registers 
are restored and the process returns to its execution point 
at the time it was interrupted. 

The scheduler makes calls to two other utility 
functions: " RDYTHISVP" and "RET$VP". " RDYTHISVP" determines 
which process is currently running by calling "RET$VP'' and 
sets it to ready. 

G. THE GATE AND GATEKEEPER 

The "Gate" module provides parameter translation and 
adjustment to facilitate processing. It directly provides 
the public link with user processes for access to system 
services. A call to the specific utility function is 
processed in the "Gate", from which a further call is made 
to the operating system "Gatekeeper ", where a final call is 
made to the specific procedure processing the requested 
service. The "Gate" module must have been provided the 



"Gatekeeper" procedure's 


address before the " 


Gate" 


was 


compiled . 


This 


address 


is 


obtained manually 


from 


the 


operating 


system 


location 


map 


in file: "K0RE.MP2" 


( see 


end 



of App . F) . 
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H. USER AVAILABLE SERVICES 

1 . Create Eventcount 

A process cannot assume that an eventcount it is 
going to use is already in existence. Any process that will 
use the eventcount must create it. The procedure is passed 
one parameter: the name of the event to be created in the 

eventcount table. It calls "Locate Eventcount" to see if 
the named event already exists. If not, it enters the name 
in the table and initializes the entry. It then increments 
the number of events; "EVENTS". If the named event is found 
when "Locate Eventcount" is called, it simply returns with 
no change. 

2 . Advance Eventcount 

The "ADVANCE" procedure increments the named 
eventcount and broadcasts this to the processes awaiting 
this particular event, via a thread. (See Chapter IV, 
Section C, Subsection 2 for an explanation of the thread.) 
To awaken a process, its state is set to ready. If the 
awakened process is associated with the same real processor, 
then the scheduler is called to reschedule all eligible 
processes (ready processes) for the real processor. If the 
awakened process is associated with another real processor, 
then the hardware interrupt flag for that real processor is 
set and an interrupt is issued. 
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3 • Await Eventcount 



''Await" is passed two arguments; (1) the event's 
name, and (2) the threshold value of the event it is waiting 
on. The current value of the named eventcount is checked. 
If the current value is less than the threshold value, the 
process is blocked and its state is set to waiting. The 
blocked process is added to the head of the thread. The 
scheduler is then called to select another eligible process 
to run. If the process is not blocked, 'Await" executes a 
return . 

4 . Read Eventcount 

"Read" is passed two parameter; (1) the eventcount 
name, and (2) a return pointer. The procedure obtains the 
current eventcount value and returns it to the calling 
process by using the pointer as a base for the value to be 
returned. With indirect calls, a value can not be returned 
directly . 

5 . Create Sequencer 

"Create Seq" is passed the name of the sequencer to 
be created. The Sequencer Table is searched by "locate Seq" 
like the Eventcount Table to see if it exists. If it 
exists, then a simple return is executed. If it does not 
exist, the name is entered into the table and the other 
entries are initialized. The number of entries in the 
table, "Sequencers", is incremented by one. As with 
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eventcounts, all processes that use a sequencer must create 
it first. They can not assume it has already been created. 

6 . Ticket Sequencer 

The "Ticket" procedure is passed two parameters; 
(1) the name of an already created sequencer and (2) a 
return pointer. Its purpose is to obtain a unique 
sequential number for the named sequencer. The current 
value is returned via the base pointer. The sequencer is 
then incremented. With indirect calls, a value can not be 
returned directly. 

7 . Create Process 

"Create Proc" is called from the initial process or 
one of the user processes. The parameter passed as input to 
the "Gatekeeper" is a pointer. The pointer is used as a 
base to a structure to overlay the data parameters supplied 
by the user. These user supplied parameters are structured 
in the "Gate". The parameters are: process ID, process 

priority, process stack segment location, process IP, and 
process CS. CS:IP is the starting address of the user 
process and it is manually obtained from the memory map 
associated with the process (the map may apply to several 
processes). Once obtained it is inserted into the initial 
module that created it. That module must then be 
recompiled, relinked, and relocated. A per-process stack is 
established and initialized. The PRDS table and number of 
virtual processors on this real processor is updated. 
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8 • Preempt Process 



"Preempt" is passed only the name of the process to 
be preempted. It searches the VPM for the process ID. When 
found, the process is set to ready and the scheduler is 
called or the processor is interrupted depending on whether 
the preempted process is the same real processor or not. 
"Preempt" is intended for high priority processes that 
block themselves when finished. 

"Preempt" was chosen as the vehicle to implement the 
second goal of this thesis. Thus, the existing frame work 
of the operating system was used to implement the "Monitor 
Process". The procedure has a second part that is executed 
if the process name is "FEH" . That name has been reserved 
for the "Monitor Process" which is described in the next 
section. The "Monitor Process" is a high priority 
diagnostic tool given to the user. Like the other system 
processes, the "Idle Process" and the "Initial Process", the 
process is associated with every real processor. "Preempt" 
has to search each real processor's set of entries in the 
VPM to find each "Monitor Process" and set each one to 
ready. It must set the hardware interrupt flags of the 
other real processors, but not its own. It issues an 
interrupt and all the other real processors are forced into 
the highest priority process, the "Monitor Process". For 
itself, the scheduler is called and it goes into the monitor 
process. With the input services that have been added to 
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MCORTEX, the monitor can be scheduled via "Preempt" on a 
regular basis or by request. 

9 . Communications with Console 

ASCII output is by single character or line. "Out 
Char" is given a single byte value and "Out Line" is given a 
pointer to the beginning of a string. The string should end 
in which will stop output. Any ASCII output can be 
stopped at the CRT by a "~S" which also freezes the process. 
ASCII output is resumed with a "~Q". This ability is useful 
to freeze diagnostic output for study. 

ASCII input is by single character and it is not 
echoed. "In Char" could easily be used to fill a buffer for 
line input. Once "In Char" has been invoked, the procedure 
waits for the character. An additional service should 
probably be added that does not wait. 

Hexadecimal input and output exists for byte and 
word values in: "Out Num" , "Out Dnum" , "In Num", and "In 
Dnum" . Output is in terruptabl e . Input is echoed for both 
byte and word values. Illegal characters are ignored. 

I. SYSTEM INITIALIZATION AND SYSTEM PROCESSES 
1 . System Initialization 

The starting address for initiating the operating 
system is found in the operating system memory map in file: 
"K0RE.MP2" (See App. F). It is usually 100:30. When the 
system is initiated, by issuing the monitor command, 
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. G 1 00 : 30<cr > , the operating system initialization routine is 
executed. The PPI and PIC are initialized as discussed in 
Chapter IV, Section E. 

Next a unique, sequential number is obtained and 
used to initialize the "CPU$NUMBER in the PRDS table for 
this processor. This is the identity of this real processor 
and is the key to the location of entries in the VPM. The 
PRDS is further initialized by using the "CPU$NUMBER" to 
calculate the beginning and ending locations in the VPM for 
this processor and by setting the number of virtual 
processors on this real processor to three. 

The VPM is then initialized for the three system 
processes. The number of real processors in the system, 
"NR$RPS", is updated to indicate another processor has been 
added to the system. ("CPU$INIT" could have been used.) 
All hardware interrupt flags are cleared and the scheduler 
is called. 

The stack used during the initialization is the 
kernel stack, which is located at the location specified in 
the execution of "LOC86 M (see App. F) . In this case, the 
kernel stack is at 3000H and its size is 75H. In order to 
initialize the stack segment, SS, and stack pointer, SP, the 
initialization routine code cannot be in a procedure block. 
It must be coded as the main routine operating system 
("KORE”) module. Neither the initialization routine or the 
kernel stack is used again during the system run time. 
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2. Process Initialization 



When the operating system initialization routine is 
completed, it calls the scheduler. The scheduler selects the 
highest priority ready process to run. Initially, that will 
always be the initial process. This process is intended to 
be the vehicle by which the user processes are established 
in the tables of the operating system. It is assumed that 
the programs are already loaded in memory as characterized 
in the creation specification. 

During the linking and locating of the operating 
system, the file, "INITK", was included and located at 
2800H. This file acts as a dummy to establish the space and 
starting location for the operating system's reference. It 
is a valid initial process module, but it will normally be 
overlayed by an "INIT" procedure modified and loaded by the 
user. The user must locate his ’’INIT" module at 2800H in 
this implementation. 

The "INIT” file must fit the prescribed format as 
provided and enough space must be reserved for it by the 
locate command. The user only modifies one area of the 
file. He provides the absolute parameters required in the 
call to the "Create Proc" procedure. One call must be made 
for each process. The user can create up to 7 processes per 
real processor for a system total of 70. 

Also, of concern to the user, is the intended stack 
location. At the desired stack location, the user must 
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allow enough space for a stack of 120H bytes. The user 
process must be coded in procedure blocks so the stack 
segment, SS, and the stack point, SP, will not override what 
is provided by the operating system. The user process 
procedure block should have the attribute "public" so that 
the address can be obtained from the location map to be used 
as parameters for process creation. See Section I, 
Subsection 7 of the chapter. 

The "INIT" process will create the processes 
specified, then block itself with a call to "Await". This 
allows the newly created processes to be scheduled and run 
according to their priorities. 

3 . The Idle Process 

The idle process has the lowest priority of any 
process. It is selected by the scheduler only if there are 
no other eligible processes (i.e., all others are blocked). 
When selected, its only function is to update the counter 
contained in the real processors own PRDS table at 
approximately one second intervals. Thus, a rough measure 
of time is obtained when this real processor is doing no 
useful work. 

4 . The Monitor Process 

This high priority system process is scheduled by 
all processors at the same time. No matter which process 
preempts the "Monitor Process", the entire system will be 
"put to sleep". The entire system address space is then 
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accessible from 


the serial port 


of 


any processor 


simultaneously . 


Each processor exits 


the 


"Monitor Process" 


individually and 


in any order. The 


user 


could leave an 


"idle CPU" in 


the monitor. However, 


the 


user must realize 



that data could be changing while he is accessing it. The 
system would then resume normal scheduling. 



A primary motivation for implementing the "Monitor 



Process" was 


that there 


was no 


way to exam 


ine memory for 


diagnostic purposes until 


after 


the system 


had run its 


course or the 


designer stopped it 


arbitrarily 


Now, memory 


can be examined 


on a synchronized 


basis with 


the occurence 


of specified 


events. A 


record 


of transac 


tions with the 


process can 


also be 


secured 


to a 


line printer 


simultaneously . 











Appendix C contains a summary of the monitor 
commands which closely mimic those of the resident monitor. 

J. METHODS AND FACILITIES 



Software development for MCORTEX was accomplished on an 
Intellec MDS 800 developmental system under the INTEL 
Systems Implementation Supervisor (ISIS-II). The MDS 800 is 
based on the 8080 microprocessor. ISIS-II is a diskette 
operating system. The MDS system has two double density 
disk drives. Object code for the 8086 is developed on the 
MDS 800 and down loaded to the 1SBC86/ 1 2 A ’ s . Readers 
unfamiliar with the ISIS-II system are refered to [Ref. 3 ]. 
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However, all source code was developed using the text 
editor, TED, from Digital Research Inc. 

There are two double density eight inch diskettes 
necessary to continue implementation of or to examine 
MCORTEX and test process source code. KLINEF.A1 contains 
module source code, relocatable code modules, executable 
code modules, memory maps and basic ISIS-II utilities. 
KLINEF.B1 contains all the module processing programs such 
as the linker, locator, assembler, and compiler. Because, 
these programs are large, they are stored on a separate 
diskette. Output from the module processing programs goes 
to KLINEF.A1. Appendix C contains annotated directory 
listings of both diskettes. 

External hardware connections required to set up the MDS 
800 and SBC's in order to facilitate communication are 
detailed in Appendices A and B. Appendix A is a detailed 
"pre-power-on" and "post-power-on" checklist to load the 
single board computers. Appendix B contains a drawing that 
describes the physical make-up of the transfer hardware. 
Cox cites a five wire RS232 cable in [Ref. 1 2 : p . 4 5 ] . 
However, only three are required. See Appendix B for 
further details. 

1 . The PL/M-86 Compiler 

As software modules must be compiled individually, 
no command files for use with the ISIS-II utility, SUBMIT, 
were established [Ref. 3*PP*3-13 to 3-1^]* The following 
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controls were found to be useful: PRINT( : LP : ) , NOPRINT, 
CODE, and LARGE. The use of the control LARGE is mandatory 
as discused earlier. It causes the compiler to represent 
addresses in such a way that the whole megabyte range of the 
8086 can be used. See Chapter III, Section C, Subsection 2 
for additional information on addressing modes. The 
following references contain more details concerning run- 
time representations by the compiler when the LARGE control 
is used: [Ref. 7-'PP-3-13 to 3-1^, 5-1 to 5-5, 8-1]. Other 
pertinent references concerning the compiler are: assembly 
language module linkage [Ref. 7:pp-9-1 to 9-33 and the 
preemptive interrupt process [Ref. 7:pp.10-1 to 10-4]. 

2 . Link86 ( Linker ) 

LNK86 takes object code modules, combines them, and 
resolves external references from each individual module. 
The resulting relocatable file has the default file 
extension, ”.LNK". Mo controls are necessary. Two command 
files, "LNKK.CSD" and "LNKP.CSD", which have been 
established can continue to be used in the future. 
''LNKK.CSD" contains the commands to link all the object code 
modules that compromise MCORTEX. "LNKP.CSD" contains the 
three commands that link the user modules into the three 
modules that will, after further processing, be loaded onto 
three SBC's. Complete error listings are given in 
[ Ref . 4 : App . A ] . 
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3 . Loc86 ( Locator ) 



Use of the locator is a little more involved. This 
program assigns addresses to the relocatable code modules 
that come from the linker. It requires knowledge of how 
modules are organized in the system address space both by 
the user, and by the operating system designer. 
[Ref. 4:Chapter 4] gives the best description of how the 
locator handles modules. The two command files, "LOCK.CSD" 
and "LOCP.CSD", established for the locator will also 
provide most of the knowledge required to locate user code. 
Eventually, after more extensive testing, MCORTEX will be 
tuned and compressed to the maximum extent possible so that 
it can be put on EPROM. Currently, modules are well 
dispersed to facilitate design and development. 

One type of output file from LOC86 is the ".MP2" 
memory map file. In addition to valuable diagnostic 
information, several critical pieces of information from 
these file are necessary for the correct operation of 
MCORTEX and the user process. There are essentially three 
items; (1) the location of the gatekeeper, (2) the starting 
addresses of user code, and (3) the starting point of the 
operating system. Warning remarks in the source code detail 
what and where these items are. In addition, later sections 
in this chapter will discuss those items. 

Upon examining any ".MP2" file, a ''WARNING 56:..." 
will at certain times appear. For example, see K0RE.MP2 in 
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Appendix E. This is caused by intensionally overlaying some 
kind of segment in space that was previously reserved. The 
warning should not cause too much concern. See the memory 
map from P03 in Appendix K for a more clear cut example. 
The effort in the last example was to prevent any code being 
put next to the initial process code. See [Ref. 4:Chap. 3] 
for more details on the controls available to the LOC86 
command . 
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V. 



CONCLUSIONS 



The pricipal goals of this thesis were met. The 
generality of MCORTEX was tested and demonstrated. Two 
problems were uncovered: (1) The interrupt mechanism does 
not appear to be totaly satisfactory and (2) the issue of an 
inactive SBC bringing down the system will eventual have to 
be addressed. The system was demonstrated with four single 
board computers and there appears to be no reason why the 
additional six cannot be added. Actual synchronized sharing 
of data was demonstrated. Two independent user systems 
operating simultaneously was demonstrated. The system was 
prevented from scheduling processes in a fixed sequence by 
introducing user interaction. User input services have been 
added to MCORTEX and a method was found within the existing 
framework of the operating system to incorporate dynamic 
interaction with the operating system itself. The total 
address space is now accessible from any single board 
computer for system debugging and examination. 
Additionally, the operating system can be continued without 
reinitializing the system. "Preempt", which had never been 
tested, is now used to evoke the "Monitor Process". 

Three possible problem areas were cited by Cox in his 
thesis. The cause of the first one was acertained. A 
weakness in the interrupt system has been clearly 
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identified. A possible problem with the eventcount thread 
was not examined as it did not immediately impact on the 
primary goals of the thesis. The third problem cited was 
the inablitiy to stop and restart the system without 
reinitializing all code. That ability now exists by 
selectively preempting the "Monitor Process". 

Future research with MCORTEX should concentrate on 
taking precise timing and performance measurements while the 
system is heavily loaded down. The second possible problem 
cited by Cox, mentioned above will also have to be examined. 
The process stacks should also be examined to dynamically 
confirm capacity usage as there are no definitive 
guidelines upon which to base stack size. A system of 
hardware interrupt ackowledge flags will probably have to be 
set up to stregthen the preemptive interrupt system. 
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APPENDIX A 



SYSTEM INITIALIZATION CHECKLIST 

I. PRE - POWER -ON CHECKS 

A. SBC * s have address translation switches and jumpers 
correctly set. 

B. SBC's have 3 interrupt jumpers set. 

C. SBC #1 has MULTIBUS clock jumper set. 

D. No other SBC has MULTIBUS clock jumper set. 

E. SBC's and common memory board full seated in odd 
slots of MULTIBUS frame. (RAM board can be in any slot.) 

F. Remove all serial CRT cables from SBC's. 

G. J2 26 pin edge connector on transfer cable can be 
hooked up to one of the SBC serial ports at this point. 

H. If RS232 transfer-cable has a "null modem" switch on 
it, set it to "null modem". This transposes wires 2 and 3* 
The switch may alternately be marked "computer to computer" 
and "computer to terminal". Set to "computer to computer". 
It should always remain in this position. 

I. Connect other end of transfer cable ( 2 5 P RS232 
connector) to 2400 baud CRT port of the MDS system. 

J. Connect any CRT to the 9600 baud TTY port of MDS 
system . 

K. Ensure CRT is set to 9600 baud. 

L. CRT that will be connected to SBC's should be set to 
9600 baud. This step is not mandatory, but recommended. 
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M. Each CRT that will be connected to SBC should have 



RS232 cable hooked up to serial port. It should lead to 
flat 25 wire ribbon and J2 connector so it can eventually be 
hooked to serial port of the SBC’s. 

II. POWER ON PROCEDURES 

A. Turn power-on key to ON at MULTIBUS frame. 

B. Press RESET near power-on key. 

C. Turn power on to all CRT's. 

D. Power up MDS disk drive. 

E. Power up MDS terminal (If not already done). 

E. Turn power-on key to ON at MDS CPU (front panel, 
upper left corner). 

F. Line printer can be turned on at any time. 

III. BOOT UP MDS 

A. Place system diskette in drive 0. Executable 
modules and SBC861 can be on another diskette in drive 1. 

B. Push upper part of boot switch in (It will remain 
in that position). 

C. Press reset and release. 

D. When interrupt light #2 lights on front panel, press 
space bar on console device. 

E. Reset the boot switch by pushing lower part of 
switch . 

F. ISIS-II will respond with 

G. Line printer can be turned on at any time. 
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IV. LOAD MCORTEX AND PROCESS MODULES 



A. Type "SBC86 1 <cr>'' . 

B. If "*CONTROL*" appears, SBC was not able to set its 
baud rate. Press RESET on MULTIBUS frame and start over. 
Once set, all SBC's should accept modules. 

C. If "Bad EMDS connection" appears, you will not be 
able to continue. Check connections. Make sure diskette is 
not write protected. Push RESET at frame. Try again. 

D. SBC861 will prompt with " . " . It will now accept any 
monitor command. 

E. Type "L KORE" . Wait for 

F. Type "L <process filename>". Wait for " . . 

G. Type "E" to exit SBC861. It is not a good policy to 
switch the transfer cable to another SBC serial port with 
out exiting SBC861. 

H. Switch transfer cable to next SBC. Go to A. 

V. RUN MULTIPROCESSOR SYSTEM 

A. Disconnect transfer cable from last SBC loaded. 

B. Connect J2 connector from each CRT to an SBC serial 
port . 

C. After all CRT's connected, push RESET on frame to 
brake baud rate. 

D. On each CRT- press "U" to obtain monitor. Will 
respond with " . " . 

E. Type "G 1 00 : 30<cr>" at each terminal to start 
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MCORTEX. If one of the SBC’s is running only MCORTEX and no 
user processes, start it first. 
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APPENDIX B 



SYSTEM INITIALIZATION HARDWARE CONNECTIONS 

The following page contains a drawing of the hardware 
connections required for transfering code developed on the 
MDS 800 to the single board computers. The transfer cable 
has two parts, an RS232 cable and a 25 wire ribbon. 

The RS232 cable has a 25P connector that mates with the 
2400 baud 25S connector on the back panel of the MDS CPU. 
The other end is a 25S connector that will mate with the 25 
wire ribbon. 

The ribbon has a 25S connector for attachment to the 
cable. The other end is a 26 pin edge connector that will 
mate with the J2 junction on the single board computer. J2 
is the serial port. The 26th pin is left unconnected on the 
edge connector. 
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APPENDIX C 



ANNOTATED DIRECTORY LISTING FOR KLINEF . A 1 



NAME .EXT REMARKS 



ATTRIB 



ISIS-II Utility. See Ref. 3 



COPY 


?» *! 


ft 


M 


DELETE 


ff ft 


ff 


M 


DIR 


!? ff 


ft 


ft 


FIXMAP 


tf ft 


ff 




HDCOPY 


ft •! 


Tf 




IDISK 


tf Tf 


ft 




LIB 


tf tf 


ft 




LIB86 


ft tf 


Tf 


Tf 


RENAME 


ft Tf 


ft 




SUBMIT 


ft tt 


Tf 


tf 



TED 

LNK 

LNKP 

LOCK 

LOCP 

GATE 

GATE 



CSD 

CSD 

CSD 

CSD 

SRC 

OBJ 



GLOBAL. SRC 
GLOBAL. OBJ 
INIT1 .SRC 
INIT2 -SRC 
INIT3 -SRC 
IN IT 1 .OBJ 
INIT2 .OBJ 
INIT3 -OBJ 
INITK .SRC 
INITK .OBJ 



KORE 

KORE 

KORE 

KORE 



LNK 

. MP 1 
, MP2 
LEVEL1 .SRC 
LEVEL 1 .OBJ 
LEVEL2 . SRC 
LEVEL2 . OBJ 
PROC1 .SRC 
PROC1 .OBJ 
PR0C2 .SRC 
PROC2 .OBJ 
PROC3 .SRC 
PROC3 .OBJ 
PROC4 .SRC 
PROC4 .OBJ 



Text editor. Not a ISIS-II utilt 
Links MCORTEX modules. Command 
Links process modules. Command 
Locates MCORTEX relocatable file 
Locates process relocatable file 
User gate module source code. 

" " " object " 

MCORTEX global data base source 
" '' " "object 

User initial process source file 



iy • 
file . 
file . 

Cmd file 
s. Cmd file 



code module. 

Tf T» 



•f 

tf 



for 1st CPU 

for 2nd CPU 

for 3rd CPU 

Compiler object code output file for 1st CPU 
" " " " " " 2nd CPU 

" " " " " " 3rd CPU 

ode module, 
ode module. 



MCORTEX initia 
MCORTEX initia 
MCORTEX reloca 
MCORTEX execut 
Linker map fil 
Locator map fi 
MCORTEX level 1 

ft *f 



User 

f! 



process 



level2 

1 

f? 

2 
tf 

3 

tf 

4 

tf 



1 process source c< 

1 process object c< 
table code file, 
able code module, 
e . 
le. 

source code module, 
object " 
source 
object 
source 
object 
source 
object 
source 
object 
source 
object 



code 

tf 



modul 

If 

tf 

*T 
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PR0C5 


.SRC 


M 


M 


5 s 


our ce 


II 






PR0C5 


.OBJ 




*r 


" 0 


b ject 


»l 






P01 


. LNK 


User 


reloca 


table 


code 


file for 


CPU 


1 . 


P01 




IT 


execut 


able 


tl 


I! IT 


11 


II 


P02 


. LNK 


M 


reloca 


table 


r, 


11 II 


I* 


2. 


P02 




II 


executable 


!T 


II II 


II 


•T 


PO 3 


.LNK 


11 


reloca 


table 


II 


II II 


f* 


3*. 


P03 




IT 


execut 


able 


If 


H IT 


IT 


IT 


POI 


. MP 1 


Linker map 


file. 










P02 


. MP 1 


IT 


II 


»T 










P03 


. MP 1 


If 




II 










POI 


. MP2 


Loca 


tor " 


IT 










P02 


. MP2 


1» 


»? 


IT 










P03 


. MP2 


»T 


M 


TT 










SBC861 




SBC 


down load program 


• 






SCHED 


.ASM 


Scheduler & 


inte 


rrupt 


handler 


assembly 






language so 


urce 


code i 


nodule . 






SCHED 


.OBJ 


Scheduler & 


interrupt 


handler 


object 






code 


module 













82 



ANNOTATED DIRECTORY LISTING FOR KLINEF.B1 



NAME .EXT REMARKS 



COPY 

DELETE 

DIR 

SBC861 
SBCIOC.LIB 
SBCIOS . LIB 
SBCIOL . LIB 
SB957A.020 
ASM86 

ASM86 .OVO 
ASM86 .OV1 
ASM86 . 0V2 
PLM86 

PLM86 .OVO 
PLM86 .OV1 
PLM86 . OV2 
PLM86 .OV3 
PLM86 .OV4 
PLM86 . OV5 
PLM86 . OV6 
PLM86 .LIB 
LINK86 
LINK86 . OVO 
LOC86 



ISIS-II utility. 

ft ft 

ft " 

MDS to iSBC86/12A down load program. 



ASM86 assembler. 



PL/M-86 compiler. 



Object code linker. 
Relocatable code locater. 
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APPENDIX D 



SBC861 & The MCORTEX MONITOR 

No up to date information on the down load program and 
the monitor for the SBC's was found. There is related 



material in [Ref. 1] and 


[Ref. 3:pp-B-179 to B-1831 only. 


The ”E" (exit) and "L" 


(load) commands are discussed in 


Appendix A. The remaining 


commands are the same as if you 


were dealing with the SBC 


monitor. Only the form using the 


two dimensional address is 


shown below. Only significant 



digits need be displayed. 



Command 


Meaning 



. dzzzz : zzzz<cr > Display contents at zzzz:zzzz. 

.dzzzz:zzzz//zzzz<cr> Displays contents starting at 



.dxzzzz : zzzz<cr> 


zzzztzzzz for zzzzH bytes. 
Same rules as above, except 
byte are decoded in to basic 


• gxxxx :xxxx<cr> 


assembly language. 
kRa d §tS?ti n gxI?tHiSS. Ixxx:xxxx 


. x<cr > 


Displays current register 
contents . 


. c [name ] <cr > 
. szzzz : zzzz 


Change register contents. 
Subsititute at zzzzrzzzz. 

If followed by next byte is 

displayed for possible 
substitution. <cr> causes 
prompt for byte value. " , " 
or <cr> causes change to take 
effect with above rules still 
applying . 
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The MCORTEX MONITOR 



The MCORTEX monitor closely parallels the command 
structure of the SBC monitor. There are only three 
commands; display, substitute, and exit. Commands are 
evaluated on a character by character basis instead of 
waiting until a buffer is filled. Once you are in the 
monitor, illegal characters are not accepted and pressing 
the wrong key will have no effect. If you enter the wrong 
command or address, follow through to start over. The full 
two-dimensional 8 hex character address must be specified, 
key. All commands are prompted for by a See Chapter 
IV. 



Command 



Meaning 



. dOOOO : 0000<cr > 
#FF 



. sOOOO : 0000 



<cr > 



00 



. e 



Display one byte at 0000:0000. 

is automatically inserted. 
Display JFH bytes starting at 
0000:0000. FFH is maximum. Once 
last digit entered, formated 
display starts. 

Space cause current contents to 
be displayed as: ”xx- M . 

Casues offset to be incremented 
and new address deisplayed. Same 
rules apply. 

Returns monitor command prompt. 
After a space and the contents 
desired are displayed as: "xx-". 

the same or a new byte value must 
be entered. 

A will continue the sequence to 

the next location. A <cr> will 
terminate it and return the prompt. 
Return the SBC to MCORTEX. This can 
be done in ANY order or not all for 
a particular terminal. 
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APPENDIX E 



LEVEL II — MCORTEX SOURCE CODE 

All of the source code in LEVEL II is contained in file: 
LEVEL2.SRC. It is compiled with the LARGE attribute. It is 
one of the relocatable code modules in file: KORE.LNK. It 
is part of the executable code module in file: KORE. A 
memory map for this module is located at the end of Appendix 
F. All operating system calls available to the user are 
located in this module. 
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/* FILE: 



LSVEL2.SRC 
KLINEF 5-20-82 



VERSION: 

PROCEDURES 



DEFINED 



GATE$KEE?ER 

READ 



CRSATE*EVC 

AWAIT 

PREEMT 

CREATS$PROC 



ADVANCE 

TICKET 



OUT *CEAR 
OUT $NUM 
S END$CHAR 
RECV $CEAR 



IN$NUM 
I N*HEX 



OUT$LINE 
OUT$DNUM 
OUT$HEX 
IN $CHAR 
IN$DNUM 



REMARKS: !!! CAUTION !!! !!! CAUTION !!! !!! CAUTION! I! 

TT? M TTC CPUIfTTPC AD? A T\ T\ E 1 "H W r\ TOT C Mr\T\ TTTT 



IF NSW USER SERVICES ARE ADDED TO THIS MODULE 
OR CHANGES ARE MADE TO EXISTING ONES, MAKS 
SURE THE LOCATOR MAP (FILE: KORE .M?2) IS CHECK- 
ED TO SEE IF THE LOCATION OF 'GATE$KEEPER ' HAS 
NOT CHANGED. THE ABSOLUTE ADDRESS OF THIS 
PROCEDURE HAS 3EEN SUPPLIED TO THE GATE*MCDULE 
IN FILE: GATE. SEC. IF IT HAS CHANGED THE NEW 
ADDRESS SHOULD BE UPDATED IN FILE: GATE. SRC 

AND RECOMPILED. ALL USER PROCESSES WILL HAVE 
TO BE RELINKED WITH FILE: GATE. OBJ AND 

RELOCATED. 

LITERAL DECLARATIONS GIVEN AT THE BEGINNING 
OF SEVERAL MODULES ARE LOCAL TO THE ENTIRE 
MODULE. HOWEVER, SOME ARE LISTED THE SAME 
IN MORE THAN ONE MODULE. THE VALUE AND 
THEREFORE THE MEANING OF THE LITERAL IS 
COMMUNICATED ACROSS MODULE BOUNDARIES. 
'NOT$FOUND' USED IN L0CATE$3VC AND 
CREATE* EVC IS AN EXAMPLE. TO CHANGE IT IN 
ONE MODULE AND NOT THE OTHER WOULD KILL 
THE CREATION OF ANY NEW SVENTCOUNTS BY THE 
OS. 
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/#007 ############*########*##£####*#*####* / 

L2$M0DULE: DO; 



y^3}:^;^5j:^3js5j:^^3}c^^?{e^3}e5t:^5t:^5t:«3&:^5j:aj5^^^3j«3j:5{c5t:^3!s^^^«5is^C5S:^^^5{c3«e^3j:«3{s^a{:^3}c^^^/ 



/* LOCAL DECLARATIONS 




V 


DECLARE 






MAX$CPU 


LITERALLY 


'10', 


MAX$7PS $ CPU 


LITERALLY 


'10', 


MAX$CPU$$$$MAX$VPS$CPU LITERALLY 


'100', 


FALSE 


LITERALLY 


'0', 


READY 


LITERALLY 


'i;. 


RUNNING 


LITERALLY 


'3', 


WAITING 


LITERALLY 


'7', 


TRUE 


LITERALLY 


'119', 


NOT$FOUND 


LITERALLY 


'255', 


PORT$CC 


LITERALLY 00CCH ' , 


RESET 


LITERALLY 


'0 ' , 


INT$RETURN 


LITERALLY 


'77H ' ; 


/^OOSS^^^^*^^^*^*^*^*^^***^*^^*^*^*^* J ’ C5ie5ic: * :3 * : * 5t:5li:3 ’ S3?i:3 ' 45j£ / 


/* PROCESSOR DATA SEGMEN 


T TABLE 


*/ 


/* DELARED PUBLIC IN 


MODULE 'Ll$MODU 


LE' */ 


/* IN 


FILE 'LE7EL1 


* «u / 

"•/ 


DECLARE PRDS STRUCTURE 






(CPU$NUMBER 


BYTE, 




VP$START 


BYTE, 




VP$END 


BYTE, 




VPS$PER$CPU 


BYTE, 




COUNTER 


WORD) 


external; 


/*01 08** ********************* *^* *********^ v ** 5i: * i:: * 3;t5jc ****** *** / 


/* GLOBAL DATA BASE DECLARATIONS 


*/ 


/* DECLARED PUBLIC IN 


FILE 'GLOBAL. 


SRC ' */ 



/* 



IN MODU LE ' GLOB AL$ MODULE' 



*/ 
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DECLASS V?M( MAX$ CPU $ $MAX $V PS i CPU 



VP$ID 


BITE , 


STATE 


3YTE , 


VP $ PRIORITY 


BYTE, 


EVC$THREAD 


BYTE, 


EV C$AW$V ALUE 


WORD, 


SSiP.EG 


WORD ) 



STRUCTURE 



EXTERNAL » 



DECLARE 

EVENTS 



BYTE 



EXTERNAL? 



DECLARE EVC $TBL (100) 
( EVC$NAME 
VALUE 
THREAD 



STRUCTURE 
BYTE, 
WORD , 
BYTE) 



external; 



DECLARE 

SEQUENCERS 



BYTE EXTERNAL? 



DECLARE SE0$TA3LE (100) STRUCTURE 
( SEQ$NAME BYTE, 

SEQ$VALUE WORD) 



external; 



DECLARE 

NR$VPS( fiAX$CPU ) BYTE 
NR$RPS BYTE 
HDW$I NT^FLAG (MAX$CPU ) BYTE 
GLOBAL$LOCX BYTE 



EXTERNAL, 

EXTERNAL, 

EXTERNAL, 

external; 



/* DECLARATION OF EXTERNAL PROCEDURE REFERENCES */ 
/* DECLARED PUBLIC IN FILE 'LEVEL1.SRC' */ 
/* IN MODULE 'LEVEL1 $MODULE ' */ 



VPS C5EDULER : PROCEDURE EXTERNAL; END; 

/* IN FILE 'SCHED .ASM ' */ 



RET $ VP : PROCEDURE BYTE EXTERNAL; END; 

LOCATESEVC : PROCEDURE ( EVENT$NAME ) BYTE EXTERNAL; 

DECLARE EVENT$NAME BYTE 5 

end; 



LOCATE$SEQ : PROCEDURE ( S SO $ NAME ) BYTE EXTERNAL; 

DECLARE SEQ$NAME BYTE 5 

end; 
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/* DIAGNOSTIC MESSAGES (WILL EVENTUALLY BE REMOVED) */ 



DECLARE 

MSG16(*) 
MSG17(*) 
MSG18(*) 
MS G19 ( * ) 
MSG21(*) 
MS G23 (* ) 
MSG24( # ) 
MS G25 ( * ) 
MSG26 ( * ) 
MS G2? ( * ) 



BYTE INITIAL! "ENTERING 
BYTE INITIAL! 'ISSUING 
BYTE INITIAL! 'ENTERING 
BYTE INITIAL! 'ENTERING 
BYTE INITIAL! 'ENTERING 
BYTE INITIAL! 'ENTERING 
BYTE INITIAL! 'ENTERING 
BYTE INITIAL ! 'ENTERI NG 
BYTE INITIAL! 'ENTERING 
BYTE INITIAL (10, 'ENTERI 



PREEMT ',13,10, '%') , 
INTERRUPT! ! ' , 13 , 10 , '% ' ) , 
AWAIT ',10,13,'%'), 
ADVANCE ',10,13,'%'), 
CREATE$EV C EOR %' ) , 

READ FOR EVC : $') , 

TICKET', 13, 10, '%') , 
CREATE$SEQ %'), 

CREATE $PROC ' ,10 ,13 ,'%' ) , 
NG GATE A KEEPER N= %')] 



DECLARE 

CR LITERALLY '0DH' , 
LF LITERALLY '0AH'J 



/####### ########:*#:£### ############## ############## ######## f 



/* 0231 ***** ********************* ****** ********* ************ / 
/** GATE$KEEPER PROCEDURE KLINEF 5-18-62 ****/ 






/* THIS PROCEDURE IS THE ENTRY INTO THE OPERATING */ 
/* SYSTEM DOMAIN FROM THE USER DOMAIN. THIS IS THE */ 
/* ACCESS POINT TO THE UTILITY/SERVICE ROUTINES AVAIL- */ 
/* ABLE TO THE USER. THIS PROCEDURE IS CALLED BY TEE */ 
/* GATE MODULE WHICH IS LINKED WITH THE USER PROGRAM. */ 
/* IT IS THE GATE MODULE WHICH PROVIDES 'TRANSLATION */ 
/* FROM THE USER DESIRED FUNCTION TO THE FORMAT RSOUIR- */ 
/* ED FOR THE GATEKEEPER. THE GATEKEEPER CALLS THE */ 
/* DESIRED UTILITY/SERVICE PROCEDURE IN LEV EL 2 OF THE */ 
/* OPERATING SYSTEM AGAIN PERFORMING THE NECESSARY */ 
/* TRANSLATION FOR A PROPER CALL. THE TRANSLATIONS ARE */ 
/* INVISIBLE TO THE USER. THE GATEKEEPER ADDRESS IS */ 
/* PROVIDED TO THE GATE MODULE TO BE USED FOR THE IN- */ 
/* DIRECT CALL. */ 
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/* THE PARAMETER LIST IS PROVIDED FOR CONVENIENCE AND */ 
/* REPRESENTS NO FIXED MEANING, EXCEPT FOR 'N'. */ 
/* N FUNCTION CODS PROVIDED BY GATE */ 
/* BYT BYTE VARIABLE FOR TRANSLATION */ 
/* » ORDS WORD " " ” */ 
/* PTR POINTER VARIABLE FOR TRANSLATION */ 



/*0 278 ****^ *********** / 

GATS$ KEEPER : PROCEDURE (N, BYT, WORDS, PTR) REENTRANT PUBLIC ♦ 



DECLARE 

(N, BYT) BYTE, 
WORDS WORD, 





PTR 


pointer; 




/* 


1-0 SERVICES ARE NOT ACKNOWLEDGED FOR TWO REASONS: 


*/ 


/* 


1 . 


THEY ARE CALLED SO OFTEN TEAT DIAGNOSTIC OUTPUT 


*/ 


/* 




WOULD BE TOO CLUTTERED. 


*/ 


/* 


2. 


THEY THEMSELVES PRODUCES 1-0 EFFECTS THAT 


*/ 


/* 




ACKNOWLEDGE THEY ARE BEING CALLED. 


*/ 




IF N < 


8 THEN DO; 





CALL OUT-LI NE( 0MSG27 ) ; 
CALL OUT-NUM(N); 

CALL OUT-CEAR(CR); 

CALL OUT$CHAR(LF) ; 



end; 



DO CASE 


n; 


/* 


N 


*/ 


CALL 


AWAIT(BYT, WORDS); 


/* 


0 


*/ 


CALL 


ADVANCE! BYT ) ; 


/* 


1 


*/ 


CALL 


CREATE-EV C ( BYT ) ; 


/* 


2 


*/ 


CALL 


CREATES SEQ ( BYT ) J 


/* 


3 


*/ 


CALL 


TICKET (BYT , PTR ) 5 


/* 


4 


*/ 


CALL 


READ( 3TT, PTR) J 


/* 


5 


*/ 


CALL 


CRSATSSPROC(PTR); 


/* 


6 


V 


CALL 


PREEMPT ( BYT ); 


/* 


7 


*/ 


CALL 


OUT-CHAR ( BYT ) J 


/* 


3 


*/ 


CALL 


OUTSLI NE( PTR ) J 


/* 


9 


*/ 


CALL 


CUT-NUM ( BYT ) J 


/* 


10 


*/ 


CALL 


OUT-DNUM ( WORDS ) J 


/* 


11 


*/ 


CALL 


I N $CHAR ( PTR ) J 


/* 


12 


*/ 


CALL 


IN-NUM (PTR) 5 


/* 


13 


*/ 


CALL 


IN-DNUM (PTR ) J 


/* 


14 


*/ 



end; /* CASE */ 
return; 

end; /* gate-keeper */ 



91 



/*0 337 ** ^* ******* / 

/* CREATE$EVC PROCEDURE KLINEF 5-18-82 */ 

/* V 

/* CREATES EYENTCOUNT FOR I NTER- PROCESS SYNCHRONIZATION. */ 
/* EVENTCOUNT IS INITIALIZED TO 0 IN THE EVENTCOUNT TABLE. */ 



CREATE$EVC : PROCEDURE ( NAME ) REENTRANT PUBLIC; 

DECLARE NAME BYTE; 

CALL 0UT$LINE((?MSG21) ; 

CALL OUT$NUM ( NAME ) J 
CALL OUTSCHAR(CR) ; 

CALL OUTSCHAR(LF) ; 

/* ASSERT GLOBAL LOCK */ 

DO WHILE LOCKSET (3GL03AL SLOCK ,119) J END; 

IF /* THE EVENTCOUNT DOES NOT ALREADY EXIST */ 
LOCATS$EVC ( NAME) = NOTSFOUND THEN DO; 

/* CREATE TEE EVENTCOUNT ENTRY BY ADDING THE */ 
/* NEW EVENTCOUNT TO THE END OF THE EVC STABLE */ 
EVCSTBL ( EVENTS ). EVC$ NAME = NAME; 

EVCSTBL (EVENTS ). VALUE = 05 

EVCSTBL ( EVENTS ). THREAD = 255 J 

/* INCREMENT THE SIZE OF THE EVC$ TABLE */ 

EVENTS = EVENTS + 1J 
END,* /* CREATE TEE EVENTCOUNT */ 

/* RELEASE THE GLOBAL LOCK */ 

GL03ALSL0CK = 0J 

return; 

END; /* CREATESEVC PROCEDURE */ 
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/* READ PROCEDURE KLINE? £-19-82 */ 

/* */ 

/* THIS PROCEDURE ALLOWS USERS TO READ THE PRESENT VALUE */ 

/* OF THE SPECIFIED EVENT$COUNT WITHOUT MAKING ANY */ 

/* CHANGES. A POINTER IS PASSED TO PROVIDE A 3ASE TO A */ 
/* VARIABLE IN THE CALLING ROUTINE FOR PASSING THE RETURN */ 
/* VALUE BACK TO THE CALLING ROUTINE. */ 






READ: PROCEDURE ( EV C$N AME , RETS$PTR ) REENTRANT PUBLIC; 



DECLARE 

SVC$NAMS 
EVCTBL$I NDFX 
RETS$PTR 
EVC$VALUS$RET 



BYTE, 

BYTE, 

POINTER, 

BASED RETS $?TR WORD * 



/* SET THE GLOBAL LOCK */ 

DO WHILE LOCKSET(GGLOBAL$ LOCK ,119) ; END; 

CALL OUT$LI NE (0MSG23 ) j 
CALL OUT$NUM(EVC$NAME)J 
CALL OUT$CHAR(CR) T 
CALL OUT$CHAR( LF) * 



/* OBTAIN INDEX */ 

SV CTBL$I NDEX = LOCATE$EVC( EVC5NAME )? 



/* OBTAIN VALUE */ 

EVC$V ALUE$RET = EVC$TBL( EVCTBL$ I NDEX ) .VALUE; 

/* UNLOCK GLOBAL LOCK */ 

GLOBAL$LCCK = 0 J 

return; 

END; /* READ PROCEDURE */ 
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/* AWAIT PROCEDURE */ 

/* */ 



/* INTER PROCESS SYNCHRONIZATION PRIMITIVE. SUSPENDS */ 

/* EXECUTION OF RUNNING PROCESS UNTIL THE EVENTCOUNT HAS */ 
/* REACHED THE SPECIFIED THRESHOLD VALUE, ”AWAITED$VALUE . "*/ 
/* USED BY THE OPERATING SYSTEM FOR TEE MANAGEMENT OF */ 
/* SYSTEM RESOURCES. */ 

AWAIT: PROCEDURE ( EVC $ID , AWAITED $ VALUE ) REENTRANT PUBLIC; 
DECLARE 

AWAITED$VALUE WORD, 

(EVCAID, NEED$S CHED, RUN N I NG $ VP , EVCTB L$ I NDEX ) BYTE; 

CALL OUT$LI NE(@MSG18 ) »* 

/* LOCK GLOBAL LOCK */ 

DO WHILE LOCK$SET (@G LOB AL$ LOCK, 119); END; 

NEED$SCHED = TRUE; 

/* DETERMINE THE RUNNING VIRTUAL PROCESSOR */ 

RUNNINGS? = RET$VP; 

/* GET EVC INDEX */ 

EV CTBL$I NDEX = LOCATE$EVC(EVC$ID)* 

/* DETERMINE IF CURRENT VALUE IS LESS THAN THE 
AWAITED VALUE */ 

IF EVC$TBL(EVCT3L$INDEX ) .VALUE < AWAITSD$ VALUE THEN DOJ 
/* BLOCK PROCESS */ 

VPM(RUNNING$VP) .STATE = WAITING; 

V?M( RUNNINGS VP ) . EVC$TEREAD=EVC STBL ( SVCTBL $ INDEX ) .THREAD 
V?M(RUNNING$VP).EVC$AW$ VALUE = AWAITEDSVALUE? 

EVC$TBL( EVCTBLS I NDEX ) .THREAD = RUNNING$VP; 

END; /* BLOCK PROCESS */ 

ELSE /* DO NOT 3L0CK PROCESS */ 

NEED$SCHED = FALSE? 

/* SCHEDULE THE VIRTUAL PROCESSOR */ 

IF NEEDSSCHED = TRUE THEN 

CALL VPSCHEDULER; /* NO RETURN */ 

/* UNLOCK GLOBAL LOCK */ 

GL03AL$L0CK = 0? 

RETURN? 

end; /* AWAIT PROCEDURE */ 
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/*053 ###*#*####*### ##########* / 



/* ADVANCE PROCEDURE KLINEF 5-19-82 */ 

/* */ 



/* INTER PROCESS SYNCHRONIZATION PRIMITIVE . INDICATES */ 
/* SPECIFIED EVENT HAS OCCURED BY ADVANCING ( INCREMENTING)*/ 
/* THE ASSOCIATED EVENTCOUNT. EVENT IS BROADCAST TO ALL */ 
/* VIRTUAL PROCESSORS AWAITING THAT EVENT. */ 

/* */ 

/* CALLS MADE TO: OUTLINE */ 

/* VP SCHEDULER (NO RETURN) */ 

**###******£ / 

ADVANCE: PROCEDURE(EVC$ID) REENTRANT PUBLIC; 



DECLARE 

( EVC$ID , NEEDSSCHED, NEED$I NTR , EVCTBL5 I NDEX ) BYTE, 

(SAVE, RUNNING$VP, I, CPU) 3YTE i 

CALL OUTALI NE ( 0MS G19 ) ? 

/* LOCK THE GLOBAL LOCK */ 

DO WHILE LOCKSET ( 3GL03AL$L0CK ,1 19 ) 5 END; 

RUNNINGAVP = RET$VP? 

EV CTB L$I NDEX = LOCATE$EVC( EVC$ID) ? 

EVC$T3L( EVCTBL$ INDEX) . VALUE=E VC $T3L(EVCTBL$ INDEX) . VALUE + 1 
NEED$S CEED = FALSE? 

NEED$ I NTR = FALSE; 

SAVE = 255; 

I = EVC^TBL ( EVCTBL$INDEX ) .THREAD? 

DO WHILE I <> 255? 

IF VPM(I) .EVC$AW$VALUE <= SVC $TBL ( EVCT3L$ I NDEX ). VALUE 
THEN DO? /* AWAKEN THE PROCESS */ 

VPM( I ) .STATE = READY? 

VPM(I).EVC$AW$VALUE = 0? 

CPU = I / MAX A VPS $ CPU ; 

IF SAVE = 225 THEN DO? /*THIS FIRST ONE IN LIST*/ 
EVC$T3L( EV CT3L$ INDEX ) . THRSAD=VPM ( I ) . EVC$THREAD ? 
VPM( I ) .EVCSTHRE AD = 255? 

I = EVC5TBL ( EV CTBL$ INDEX ). THREAD? 

END? /* IF FIRST */ 

ELSE DO? /* THEN THIS NOT FIRST IN LIST */ 

VPM ( SAVE ) . EVC ^THREAD » VPM( I ) .EVC$THREAD? 

VPM( I ).EVC$THREAD = 255? 

I = VPM ( SAVE ) .EVC$THREADJ 
end; /* IF NOT FIRST */ 

IF ( CPU <> PRDS .CPUSNUMBER ) THEN DO? 

HDW$INT$FLAG ( CPU ) = TRUE? 

NEED$INTR = TRUE? 

end; 
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ELSE NEEDASCHED = TRUE* 

END,* /* IF AWAKEN */ 

ELSE DO? /* DO NOT AWAKEN THIS PROCESS */ 

SAVE = i; 

i = vpm ( i ).evc$thread; 

END; /* IF NOT AWAKEN */ 

END; /* DO WHILE */ 

IF NEED$ INTR = TRUE THEN DO; /* HARDWARE INTR */ 
CALL OUT$LI NE( 0MSG1? )J 
DISA3LE * 

OUTPUT ( PORTACC ) = 80HJ 
CALL TIMS Cl)* 

OUTPUT ( PORT$CC ) = RESET * 

enable; 

END; /* NEED$ INTR */ 

IF NEED$SCHED = TRUE THEN DO? 

VPM(RUNNlNGiVP) .STATE = READY; 

CALL VPSCHEDULER; /* NO RETURN */ 

END; /* IF NEED$SCHED */ 

/* UNLOCK THE GLOBAL LOCK */ 

GLOBAL$LOCK = 0J 

return; 

end; /* ADVANCE PROCEDURE */ 
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/* PREEMT PROCEDURE KLINE? 5-19-62 */ 

j ___ _____ __ _ __ __ _ _ ijc i 

/* THIS PROCEDURE AWAKENS A HI PRIOITY PROCESS LEAVING */ 
/* THE CURRENT RUNNING PROCESS IN THE READY STATS AND */ 

/* CALLS FOR A RESCHEDULING. THE HIGH PRIORITY PROCESS */ 

/* SHOULD BLOCK ITSELF WHEN FINISHED. */ 

/* IF THE VP$I D IS 'FE ' OR THE MONITOR PROCESS, IT WILL */ 
/* MAKS IT READY WHERE-EVER IT IS IN THE 7PM. THE FOLLOW-*/ 
/* ING CODE DOES NOT TAKE ADVANTAGE OF THE FACT THAT */ 

/* CURRENTLY IT IS THE THIRD ENTRY IN THE VPM FOR EACH */ 



/* REAL PROCESOR. */ 

/* */ 

/* CALLS MADE TO: OUTLINE, VPSCHEDULER */ 



a;:########;!!##**#*# / 



PREEMPT: PROCEDURE( V?$ID ) REENTRANT PUBLIC? 

DECLARE (VP$ID,SEARCH$ST,SEARCH$END, CPU, INDEX) BYTE? 

CALL OUT$LINE( 3MSG16 )? 

IF VP$ ID <> 0FSH THEN DO? /* NORMAL PREEMT */ 

/* SEARCH VPM FOR INDEX FOR ID */ 

SEARCH$ST = 0? 

DO CPU = 0 TO (NR$RPS - 1) J 

SEARCH$END * SEARCH$ST + NR$VPS( CPU ) — 1 5 
DO INDEX = SEARCH$ST TO SEARCH$END? 

IF VPM ( INDEX ).VP$ID = VP$ID THEN GO TO FOUND? 
END? /* DO INDEX */ 

SEARCH$ST = SEAP.CH$ST + MAX$VPS$C?U? 

END; /* DO CPU */ 

/* CASE I? NOT FOUND IS NOT ACCOUNTED FOR CURRENTLY */ 
FOUND: 

/* LOCK THE GLOBAL LOCK */ 

DO WHILE LOCK$SET (GGLOBAL SLOCK ,119) ? END * 

/* SET PREEMPTED VP TO READY */ 

VPM ( INDEX ). STATS = READY; 

/* NEED HARDWARE INTR OR RE-SCHED */ 

IF ( CPU = PRDS .CPUS NUMBER ) THEN DO; 

INDEX = RET$VP5 /* DETERMINE RUNNING PROCESS */ 
VPM ( INDEX ). STATE = READY? /* SET TO READY */ 
CALL VPSCHEDULER? /* NO RETURN */ 

END? 

ELSE DO? /* CAUSE HARDWARE INTERRUPT */ 

CALL OUT$L INE( GMSG17 ) ; 

HDW$INT$FL AG ( CPU ) = TRUE? 

DISABLE? OUTPUT' PORT$CC ) = 80H; 

CALL TIME( 1) ? 

OUTPUT ( PORTSCC ) = RESET; ENABLE? 

END? 

END? /* NORMAL PREEMT */ 
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ELSE DO; /* PREEMT THE MONITOR */ 

/* SEARCH 7PM EOR ALL ID'S OF 0FEH */ 

SEARCE$ST = 0J 

DO WHILE LOCK$SET(GGLOB AL$ LOCK ,119) ; END? 

DO CPU = 0 TO (NR$RPS - 1) ; 

SEARCE$END = SEARCH^ST + NR$VPS( CPU ) - 15 
/* SET ALL INT$FLAGS EXCEPT THIS CPU'S */ 
IF PRDS . CPUS NUMBER <> CPU THEN 
HDW$INT$FLAG( CPU ) = 'TRUE? 

DO INDEX = SEARCH$ST TO SEARCH$ENDJ 
I F VPM ( INDEX ).VP$ID = VP$ID THEN 
VPM ( INDEX ). STATE = READY » 
end; /* DO */ 

SEARCH$ST = S EARCH$S T + MAX$VPS$CPU; 

END? /* ALL MONITOR PROCESS SET TO READY */ 

/* INTERRUPT THE OTHER CPU'S AND 
RESCHEDULE THIS ONE */ 

CALL OUT$LINE((?MSG17) ; 

disable; 

OUTPUT ( ?ORT$CC ) = 80H ; 

CALL TIME ( 1 ) 5 

OUTPUT ( POPlT$CC ) = reset; 
enable; 

INDEX = RET$VP; 

VPM( INDEX) .STATE = READY ; 

CALL 7PSCHEDULER; /* NO RETURN */ 

END; /* ELSE 

/* UNLOCK GLOBAL MEMORY */ 

GLOBAL$LOCK = 0? 

return; 

end; /* PREEMPT PROCEDURE */ 
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/* @7 gg**************** ******** 
/* ~ CPEATSSSEQ PROCEDURE 




/* CREATOR OF INTER PROCESS SEQUENCER PRIMITIVES FOR USSR */ 
/* PROGRAMS . CREATES A SPECIFIED SEQUENCER AND INITIAL- */ 
/* IZES IT TO 0, BY ADDING THE SEQUENCER TO THE END OF THE*/ 



CREATE$SEQ: PROCEDURS( NAME ) REENTRANT PUBLIC; 

DECLARE NAME 3YTE5 

/* ASSERT GLOBAL LOCK */ 

DO WHILE LOCKS ET ( @GLOBAL$LOCK , 1 19 ) ; END; 

CALL OUT$LI NE (0MSG25 ) 5 
CALL OUT$EEX(NAME); 

CALL OUT$CHAR(CR); 

CALL OUT$CHAR(LF) J 

IF /* THE SEQUENCER DOES NOT ALREADY EXIST, IE */ 
LOCAT E$SEQ ( NAME) = NOT$FOUND THEN DO; 

/* CREATE THE SEQUENCER ENTRY BY ADDING THE */ 
/* NEW SEQUENCER TO THE END OF THE SEQ$TA3LE */ 
SEQ$T ABLE (SEQUENCERS ) .SEQSNAME = NAME; 
SEQ$TABLE(SEQUENCERS ) .SEQ$VALUE = 05 

/* INCREMENT NUMBER OF SEQUENCERS */ 
SEQUENCERS = SEQUENCERS + l; 

END? /* CREATE THE SEQUENCER */ 

/* RELEASE THE GLOBAL LOCK */ 

GLOBAL$LOCK = 0; 

return; 

end; /* CREATE$SEQ PROCEDURE */ 



/* SEQUENCER TABLE. 

/* 

/* CALLS MADE TO: 

/* 



OUT$LINE 

OUT$HEX 



OUT $ CHAR 
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/* 0 86 5 ** *^****^************^ ************* / 

/* TICKET PROCEDURE KLINE? 5-20-82 */ 

/* */ 

/* INTER-VIRTUAL PROCESSOR SEQUENCER RPIMITIVE ?OR USER */ 
/* PROGRAM. SIMILAR TO "TAKE A NUMBER AND WAIT." RETURNS*/ 
/* PRESENT VALUE OF SPECIFIED SEQUENCER AND INCREMENTS THE*/ 
/* SEQUENCER. A POINTER IS PASSED TO PROVIDE A BASE TO A */ 
/* VARIABLE IN THE CALLING ROUTINE FOR PASSING THE RETURN */ 



/* VALUE BACK TO THE CALLING ROUTINE. */ 

/* */ 



/* CALLS MADE TO: OUT$LINE */ 



TICKET: PROCEDURE ( SEQ$NAME, RETS $?TR ) REENTRANT PU3LIC 5 



DECLARE 

SEQ$NAME 
SEQ.T3L$INDEX 
RETS iPTR 
SEQ$VALUE$RET 



BYTE, 

3YTE, 

POINTER, 

BASED RETS$PTR WORD; 



/* ASSERT GLOBAL LOCK */ 

DO WHILE L0CKSET((?GL03AL$L0CK , 119) J END; 



CALL OUT$LI NE ( GMSG24 ) ; 



/* OBTAIN SEQ$NAME INDEX */ 

SEQTBL$INDEX = LOCATE$SEQ( SEQ$N AME ); 

/* OBTAIN SEQUENCER VALUE */ 

SEQ$VALUE$RST = SSQ$TABLE( SEQT3L$INDSX ).SSO$VALUE5 
/* INCREMENT SEQUENCER */ 

SEQ.$TABLE( SEQTBL$I NDEX ).SEQ$VALUE = 

SEQ$ TABLE ( SEQT3L$ INDEX ) .S EQ$ VALUE + 1 ? 

/* UNLOCK THE GLOBAL LOCK */ 

GLOBAL$LOCK = 0 ; 

RETURN 5 

END; /* TICKET PROCEDURE */ 
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7*0931 

/* CREATE$PF.0C PROCEDURE XL IN EE 5-20-32 

/* 

/* THIS PROCEDURE CREATES A PROCESS FOR THE USER AS 

/* SPECIFIED 3T THE INPUT PARAMETERS CONTAINED IN A 
/* STRUCTURE IN THE GATE MODULE. THE PARAMETER PASSED 
/* IS A POINTER WHICH POINTS TO THIS STRUCTURE. 

/* INFO CONTAINED IN THIS STRUCTURE IS: PROCESS ID, 

/* PROCESS PRIORITY, THE DESIRED PROC STACK LOCATION, 

/* AND THE PROCESS CODE STARTING LOCATION WHICH IS 
/* IS TWO ELEMENTS: THE IP REGISTER (OFFSET) AND THE 
/* CS REGISTER (CODE SEGMENT). 

/* 

/* CALLS MADE TO: OUTLINE 



*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 

*/ 






CREATE$PROC: PROCEDURE ( PROC$PTR ) REENTRANT PUBLIC? 



DECLARE 

PROC$ PTR POINTER, 

PR0C$TA3LE BASED PROC$PTR STRUCTURE 
( PROC$ID BYTE, 

PROC$PRI BYTE, 

PROC $S TACK $SEG WORD, 

PROC$IP WORD, 

PROC$CS word); 



DECLARE 

(PS1, PS2 ) WORD, 
TEMP byte; 



DECLARE PROC$STACK$PTR POINTER AT(0PS1), 

PROC$STACK BASED PROCiSTACK$PTR STRUCTURE 



(SP WORD, 

BP WORD , 

RETiTYPE WORD, 

LENGTH(0FEH ) BYTE, 

DI WORD, 

SI WORD, 

DS WORD, 

DX WORD, 

CX WORD, 

AX WORD, 

BX WORD, 

ES WORD, 

IP WORD, 

CS WORD, 

FL WORD); 



CALL 0UT$LINE(0MSG26) ; 
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/* TO SET UP PROC$STACK$PTR */ 
PS1 = 05 

PS 2 = proc$table.proc$stack$seg; 



PROC$STACK.SP = 104H; 

PROC$STACK . BP = 0J 

PROC $S TACK. RET iTYPE = INT$RETURNJ 

PROC$STACK.DI = 0; 

PROC$STACK.SI = 0; 

PROC$STACK.DS = 0? 

PROC$STACK . DX = 0; 

PROC^STACK.CX = 0? 

PROCiSTACK . AX = 0J 
PROC$STACK.BX = 0J 



PROC$STACK . ES 
PROC$ STACK . IP 
PROC$STACK . CS 
PROCSSTACK.FL 



0 . 

PRO C$ TABLE . PPOC$IPJ 
PROC STABLE . PROC $CS ; 

200H; /#SET IE FLAG (ENABLE INTR)*/ 



/* SET GLOBAL LOCK */ 

DO WHILE LOCKSET ( 0GLOBAL$LOCK ,119) ; END; 



IE PRDS .VPS$?ERSCPU < MAX$VPS$CPU THEN DO; 

TEMP = PRDS .VPS$PER$C?U + PRDS . VPSSTART ; 

VPM ( TEMP ) . VPSI D = PRO CITABLE .PROC 5 ID* 

VPM ( TEMP ). STATE = 01 ; /* READY */ 

VPM ( TEMP ) .VPSPRIORITY = PROC5TA3LE. PROC $PRI J 
VPM ( TEMP ).EVC$TEREAD = 255J 
VPM ( TEMP ) .EVC$AW$VALUE = 0? 

VPM ( TEMP ).SS$REG = PR OC$ TABLE . PROCSS TACK $S EG ; 

PRDS .VPSSPSRSCPU = PRDS .VPSSPSRSCPU + l; 

PRDS . VPSEND = PRDS . VP$END + i; 

NR$ VPS ( PRDS .CPUSNUMBER ) = 

MRS VPS (PRDS . CPU $ NUMBER) + 1J 
END; /* DO */ 



/* RELEASE THE GLOBAL LOCK */ 
GLOBALSLOCK = 0? 

return; 

end; /* CRSATE$PP.OC ESS */ 
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/# 106 3^**^*^***^*^*^^****^^*^**^*^***^*******^**** ****** / 
/* IN$CHAR PROCEDURE KLINEF 5-22-62 */ 

/# */ 

/* GETS A CHAP FROM THE SERIAL PORT. CHAR IS ! ! ! NOT ! ! ! */ 

/* ECHOED. THAT IS RESPONSIBILTY OF USER IN THIS CASE. */ 
/* INPUT TO SERIAL PORT VIA SBC861 DOWN LOAD PROGRAM MAY */ 
/* NOT BE ACCEPTED. */ 

/* POINTER IS PROVIDED BY USER SO EE CAN BE RETURNED TEE */ 
/* CHARACTER . */ 

/* CALLS MADE TO: REC V$CAHR */ 

/#:£##################### 5£:$c#5*t:(s ## 3 $: ^ ^ :£ £ # # # $ / 

IN$CHAR: PROCEDURE ( RET$PTR ) REENTRANT PUBLIC,* 

DECLARE 

RETSPTR POINTER, 

INCHR BASED RET$?TR BYTE? 

disable; 

INCHR = recUcear; 

enable; 

return; 

end; /* in$char */ 



/* IN$NUM PROCEDURE KLINEF 5-22-62 */ 

/* */ 



/* GETS TWO ASCII CHAR FROM THE SERIAL PORT, EXAMINES */ 
/* THE M TO SEE IF THEY ARE IN THE SET 0..F HEX AND FORMS */ 
/* A BYTE VALUE. EACH VALID HEX DIGIT IS ECHOED TO THE */ 



/* CRT. IMPROPER CHAR ARE IGNORED. NC ALLOWANCES ARE */ 
/* MADE FOR WRONG DIGITS. GET IT RIGHT THE FIRST TIME. */ 
/* IF YOU ARE INDIRECTLY ACCESSING THE SERIAL PORT VIA */ 
/* THE SBC861 DOWN LOAD PROGRAM FROM THE MDS SYSTEM */ 
/* INPUT MAY NOT BE ACCEPTED. A POINTER IS PASSED BY TEE*/ 
/* USER SO THAT HE RETURNED THE CHARACTER. */ 

/# at. / 



/* CALLS MADE TO: IN$EEX */ 



IN$NUM: PROCEDURE ( RSTSPTR ) REENTRANT PUBLIC; 

DECLARE 

RET$?TR POINTER, 

NUM BASED RET$PTR BYTE; 

DISABLE; 

NUM = IN$HEXJ 

enable; 

return; 

end; /* I N$ NUM */ 
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/# i 1 29 **************** ❖£*###❖#*###*####### *####### #*####*## / 

/* OUT$CHAR PROCEDURE KLINE? 5-20-82 */ 

/* */ 

/* SENDS A BYTE TO THE SERIAL PORT */ 

/* V 

/* CALL MADE TO: S END$CHAR V 

/# ####:jc$*#:fc:<c#:Oc#:fcXc#:«c:(c ##########:<£# tfJ**####*## #5}: ijsj}:##:*:#:########*/ 

OUT$CHAR : PROCEDURE( CHAR ) REENTRANT PUBLIC? 

DECLARE CHAR BITE? 



DISABLE? 

CALL SEND$CHAR ( 

enable; 

return; 

!nd; 



char ); 



/+ 1153 ****************** ****#**#**#**#***#**#*#******#***** / 



/* 

/*- 

/* 

/* 

/* 

/* 

/*' 

/* 



OUT$LI NE PROCEDURE 



KLINSF 5-20-82 



*/ 

_ _____ %, i 

US I NS A POINTER TO A BUFFER IT WILL OUTPUT AN ENTIRE */ 

LINE THRU THE SERIAL PORT UNTIL AN '%' IS ENCOUNTERED */ 
OR 30 CHARACTERS IS REACHED— VHI CH EVER IS FIRST. CR'S*/ 
AND LF'S CAN BE INCLUDED. */ 

CALLS MADE TO: SEND$CHAR */ 



/He#######*::* *### ####:£ s**## ## ###:«£ 5*### ####♦♦ ajcaje^fe^ a«c / 



OUT5LINE: PROCEDURS( L I NE$PTR ) REENTRANT PUBLIC? 
DECLARE 

LINE$PTR POINTER, 

LINE BASED LINE5PTR (80) BYTE, 

II 3YTE5 

disable; 

DO II = 0 TO 79? 

IF LI NE ( II ) = '%' TEEN GO TO DONE J 
CALL SEND$CHAR ( LI NE( II ) ) 5 

end; 

DONE: ENABLE? 

return; 

end; 
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/# 1 ! 
/* CUT$NUM PROCEDURE KLINEF 5-23-82 */ 

/# * / 

/* OUTPUTS A BYTE VAULE NUMBER THRU THE SERIAL PORT */ 

/* */ 

/* CALLS MADE TO: OUT^EEX */ 

OUT$NUM : ?ROCEDURE( NUM ) REENTRANT PUBLIC* 

DECLARE NUM BYTE? 

disable; 

CALL OUT$HEX ( NUM )J 
ENA3LE* 

return; 

end; 



/*\21Q***** *************************************** ********* / 



/* I N$DNUM PROCEDURE KLINEF 5-22-82 */ 



/* GETS FOUR ASCII FROM SERIAL PORT TO FORM WORD VALUE. */ 
/* CRITERIA ARE THE SAME AS IN PROCEDURE IN$NUM. */ 

/* */ 

/* CALLS MADE TO: IN$HEX */ 



IN$DNUM: PROCEDURE ( RET$PTR ) REENTRANT PUBLIC; 

DECLARE 

RET$PTR POINTER, 

DNUM BASED RET$PTR WORD, 

(H, L) word; 

disable; 

H = IN$HEXJ 

h = shl ( h, e ); 

L = IN$HEXJ 
DNUM = (H OR L); 

enable; 

return; 

end; 
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/# 126 ^ ## ^^3jc^^5^3^af:a}c3?:3t:^3}c^e^;^3p^3?:^^ / 

/* OUT$DNUM PROCEDURE XLINEF 5-20-62 */ 

/* */ 

/* OUTPUTS A WORD VALUE NUMBER VIA THE SERIAL PORT */ 

/* */ 

/* CALLS MADE TO: OUT$HEX */ 



OUT$DNUM: PROCEDURE( DNUM ) REENTRANT PUBLIC; 



DECLARE 

DNUM WORD, 

SEND byte; 



disable; 

SEND = HIGH ( DNUM )? 
CALL OUTSHEX ( SEND ); 
SEND = LOW ( DNUM )J 
CALL OUT$HEX ( SEND ),* 

enable; 

return; 

end; 



/#! 28 Q# 3 * s^5{t ** ### #$$### / 



/* REC V$C3AR PROCEDURE XLINEF 5-22-32 */ 

. _ j 

/* EC'TTEM LEVEL PROCEDURE THAT OBTAINS A CHAR PROM THE */ 

/* SERIAL PORT. PARITY BIT IS REMOVED. CHAR IS ! ! NOT ! ! */ 
/* ECHOED. */ 

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — ^ / 

/* CALLS MADE TO: NONE */ 






RECV$CHAR: PROCEDURE 3YTE REENTRANT PUBLIC? 

DECLARE 

CER byte; 

/*CHECE PORT STATUS BIT 2 FOR RSCEI VE-READY SIGNAL */ 
DO WHILE ( I N?UT( 0DAH ) AND 02H) = 0? END? 

CHR = ( INPUT (0D8H) AND 07FH); 

RETURN CHR? 

end; 
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/* S 2ND $ CHAR PROCEDURE KLINEF 5-22-62 */ 

/* */ 

/* OUTPUTS A BYTE THRU THE SERIAL PORT. THIS IS NOT A */ 

/* SERVICE AVAILAELE THRU TEE GATEKEEPER EUT IT IS CALLED*/ 

/* BY MANY OF THOSE PROCEDURES. IT WILL STOP SENDING */ 

/* (AND EVERYTHING ELSE) IF IT SEES A ~S AT INPUT. ~Q */ 

/* WILL RELEASE THE PROCEDURE TO CONTINUE. */ 

/* TEE USER BEWARE!!!!! THIS IS ONLY A DIAGNOSTIC TOOL */ 

/* TO FREEZE TEE CRT FOR STUDY. RELEASING IT DOESN'T */ 

/* ASSURE NORMAL RESUMPTION OF EXECUTION. (YOU MAY FORCE*/ 

/* ALL BOARDS TO IDLE FOR EXAMPLE.) */ 

/* */ 

/* CALLS MADE TO: */ 

/£############## ####£##### # # 3{c # # # ## # # $ SjC * # # # ## ifc # # # ## S^C / 

SEND$CHAR: PROCEDURE ( CHAR ) REENTRANT PUBLIC *’ 

DECLARE (CHAR , INCHR ) BYTE! 

/* CHECK PORT STATUS V 
INCHR = ( INPUT (0D8H) AND 07FH ) J 
IF INCHR = 13H THEN 

DO WHILE (INCHR <> 11H)J 

IF ( (INPUT(0DAH) AND 02H) <> 0) THEN 
INCHR = ( I NPUT ( 0D8H ) AND 07FH); 

end; 

DO WHILE ( INPUT ( 0DAH ) AND 01H) = 0? END; 

OUTPUT (0D8H ) = CHARJ 

return; 

end; 
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/* I N$HEX PROCEDURE XLINEF 5-22-S2 */ 



/* */ 

/* GETS 2 HEX CHAR FROM THE SERIAL PORT AND IGNORES ANT- */ 
/* THING ELSE. EACH VALID HEX DIGIT IS ECHOED TO THE */ 
/* SERIAL PORT. A BYTE VALUE IS FORMED FROM THE TWO HEX */ 
/* CHAR. */ 
/* V 



/* CALLS MADS TO: RECVSCHAR */ 



INiHEX: PROCEDURE BITE REENTRANT PUBLIC; 



DECLARE 

ASCII (*) BYTE DATA ( '0123456789ABCDEF ' ) , 

AS Cl I L( * ) BYTE D ATA ( '0123456789 ', 61H ,62H ,63H ,64H , 65H . 
66H ) , 

(INCHR, HEXNUM , H, L) BYTE, 

FOUND BYTE, 

STOP BYTE; 

/* GET HIGH PART OF BYTE */ 

FOUND = 0J 
DO WHILE NOT FOUND; 

/* IF INVALID CHAR IS INPUT, COME BACK HERE */ 

INCHR = recv$char; 



h = 0 ; 
stop = 0 ; 
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/* COMPARE CHAR TO HEX CHAR SET */ 

DO WHILE NOT STOP? 

IF (INCHR=ASCIHH) ) OF: (INCHR = ASCIIL(H)) THEN DO 
STOP = 0FFH; 

FOUND = 0FFHJ 

CALL SEND$CHAR ( INCH? )? /* TO ECHO IT */ 

end; 

ELSE do; 

H - h + IS 

IF E * 10H THEN STOP = 0FFH; 

END; /* ELSE */ 

END; /* DO WHILE */ 

H = SHL ( H, 4 ); 

END; /* DO WHILE */ 

FOUND = 0? 

/* GET LOW PART OF BYTE */ 

DO WHILE NOT FOUND; 

/* AGAIN DO UNTIL VALID HEX CHAR IS INPUT */ 

INCHR = recv$char; 
l = oh; 
stop = z; 

DO WHILE NOT STOP; 

IF ( INCHR=ASC 1 1 (L ) ) OR ( I NCHR=ASC 1 1 L v L ) ) THEN DO? 
STOP = 0FFHJ 
FOUND = 0FFH; 

CALL SEN D$ CHAR (INCHR ) J 

end; 

ELSE do; 

L = L + i; 

IF L = 10H TEEN STOP = 0FFHJ 
END; /* ELSE */ 

END; /* DO WHILE */ 

end; /* do while */ 

RETURN (H OR L); 
end; /* I N$HEX */ 
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/sjc 1 52 5 ########*########*################*#*#### #######*##*# / 



/* OUT$HEX PROCEDURE KLINSF 5-20-82 */ 

/* */ 

/* TRANSLATES BYTE VALUES TO ASCII CHARACTERS AND OUTPUTS*/ 

/* THEM THRU THE SERIAL PORT */ 

/* */ 

/* CALLS MADE TO: SEND$CHAF. */ 



/ 5* *r # # J* # # # Sr * s!t # # jJC # # # S}S j)t j)t # 5^ jjt * # # if # # # 5jt Jjt *! 3}£ # # £ 5{{ # jjt # if if jjt 3jS # if if =jt # Sjt if jjt # sjt sjs if # / 

OUT$HEX : PROCEDURES ) REENTRANT PUBLIC J 
DECLARE E BYTE? 

DECLARE ASCIIS) BYTE DATA ( '0123456789A3CDEF ' ) ; 

CALL S END$ CHAR ( ASCI I (SHR(B,4) AND 0FH))J 
CALL SEND$CHAR (ASCII (B AND 0FH ) ) ; 

return; 

end; 

END? /* L2$H0DULE */ 
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APPENDIX F 



LEVEL I — MCORTEX SOURCE CODE 



All of the source code in LEVEL I, except the scheduler 
and interrupt handler, is contained in file: LEVEL1.SRC. 
It is compiled with the LARGE attribute. The two exceptions 
are written in ASM86 and had to be listed in their own 
module. LEVEL I is one of the relocatable code modules in 
file: KORE.LNK. It is part of the executable code module 
in file: KORE. This module contains utility procedures 
used only by the operating system. The memory map for all 
of KORE is located at the end of this Appendix. The map 
comes from file: K0RE.MP2. 



/ «l< «U tV «JU «**o »V •*' *V <tlf »■» «Jko *Jo*Jo *.!» »l* »<• wO >v ■«■*» «V »** <*Ao y< ■>*« v« Jf y» »V *.<» «V ■Jo Uo »’o »*o «Jo Jo vV <Jo *.'o Jo Uo »U «v »*o Jo Jo / 

'p¥^'J?3p¥¥¥'r'r n t 'r¥n t 'rT* 3 J t< r < rT , i' vt »(' J r , ‘r tii* / 

/ ,lo «<o Jo Jo Jo Jo «lo Jo «<o Jo «>o Jo Jo Jo \lo Jo «*o Jo Jo Jo Jo Jo Jo Jo Jo Jo Jo Jo Jo Jo Jo Jo Jo Jo » l o »*o Jo Jo Jo Jo Jo >'o Jo Jo »'o Jo «lo «<o »*o *<o Jo »<o Jo Jo Jo »*o Jo Jo / 

Op o-p OJ« o\» Jf. op Of. Of. -op. oji Of* Op Op op ?p op op op 5p op op Op op 0 , 0 . op op op op op Op op op op Op Of* op Of* op op op op op op op op op op op Of* Op Of* op op 3p op op op op / 



/ s 



FILE: 
VERSION : 



LEVEL1.3RC 
KLINE? 5-25-62 



PROCEDURES 

DEFINED: 



RET $VP 
GET WORK 
LOC ATE$SEO 
MON ITOR$PROC 



RDYTHISVP 
LCCATESEVC 
I DLE$PROC 



REMARKS : 

WARNING: SEVERAL OF TEE LITERAL DECLARATIONS BELOW 

HAVE A SIMILAR MEANING IN OTHER MODULES. THAT MEAN- 
ING IS COMMUNICATED ACRCSS MODULES BOUNDARIES. 3E 
CAREFUL WHEN CEANGING THEM. 

V 

### ######:£ ######:£## y 



LI ^MODULE : DO; 



/*QQ24:******************** ****** *************** ************ / 



/* LOCAL DECLARATIONS 



*/ 



DECLARE 



MAX$CPU 


LITERALLY 


'IV' . 


MAXSVPS S CPU 


LITERALLY 


'10'. 


MAX$CPU$ $$MAX$VPS$CPU 


LITERALLY 


'100 ' . 


FALSE 


LITERALLY 


'0'. 


READY 


LITERALLY 


' 1 '. 


RUNNING 


LITERALLY 


'3 ' , 


WAITING 


LITERALLY 




TRUE 


LITERALLY 


'119' . 


NOTSFOUND 


LITERALLY 


'255', 


PORTSC0 


LITERALLY 


'00C0H ' . 


PORTS C 2 


LITERALLY 


'00C2H ' , 


PORTSCE 


LITERALLY 


'30CEH ' , 


PORTS CC 


LITERALLY 


'00CCH ' , 


RESET 


LITERALLY 


'0'. 


I NTSRETURN 


LITERALLY 


'775 ' , 


IDLE$STACK?SEG 


LITERALLY 


'0310H ' , 


IDLESSTACKSABS 


LITERALLY 


'03100H ' , 


IN ITSSTACKSSEG 


LITERALLY 


' 0320H ' , 


I N I TSSTACKSA3S 


LITERALLY 


'03200H' , 


MONITORSSTACK$SEG 


LITERALLY 


' 0330H ' . 


MON I TORS STACK SABS 


LITERALLY 


'03300H'? 
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/ # 0 07 3 ^ ^ S * S3 * S5 » 6S « C ## ## 

/* PROCESSOR DATA SEGMENT 



'i' ^ ^ ^ ^ ^ -r 'i 5 '? *t' ^ 'r* ^r* ^r* 'i' o' '‘J* ^ ^r 5o -v n* ^}6 'r o' ^i~ 2t~ 2? f 

table */ 



/* information relevant to the particular physical */ 

/* PROCESSOR on which it is resident. */ 

/* */ 
/* C?U$NUMBER : UNIQUE SEQUENTIAL NUMBER ASSIGNED TO */ 

/* THIS REAL PROCESSOR. */ 

/* V?$ST ART : VPM INDEX OF THE FIRST VIRTUAL */ 

/* PROCESS ASSIGNED TO THIS REAL CPU. */ 

/* VP$END: INDEX IN VPM OF LAST VIRTUAL... */ 

/* VPS APERACPU : THE NUMBER OF VP ASSIGNED TO THIS */ 

/* REAL CPU. MAX IS 10. */ 

/* COUNTER: AN ARBITRARY MEASURE OF PERFORMANCE. */ 

/* COUNT MADE WHILE IN IDLE STATE. */ 



DECLARE PRDS STRUCTURE 



(CPU$NUM3ER BYTE, 

VP$START BYTE, 

VP5END BYTE, 

VPS $?ER$ CPU BYTE, 

COUNTER WORD) 



PUBLIC INITIALS, 0,0, 0,0)? 



/* GLOBAL DATA BASE DECLARATIONS */ 
/* DECLARED PUBLIC IN FILE 'GLOBAL. SRC' */ 
/* IN MODULE 'GL03AL$M0DULE ' */ 



DECLARE VPM ( MAX$C?U$$$$MAX$V?S$C?U 
( VPS ID BYTE, 



STATE BYTE, 
VpSPRIOR ITY BYTE, 
EVC$THREAD BYTE, 



EVC$AW$ VALUE WORD, 

SSSREG WORD) EXTERNAL ? 



STRUCTURE 



DECLARE 

CPU$I NIT BYTE EXTERNAL. 

HDWSINT$FLAG( MAX$CPU ) BYTE EXTERNAL, 

NR $ VPS ( MAX$ CPU ) BYTE EXTERNAL, 

NR$RPS BYTE EXTERNAL, 

GLOBALiLOCK BYTE EXTERNAL? 



D"E C LAR 5 

EVENTS BYTE EXTERNAL, 

SVC$TBL( 100 ) STRUCTURE 
( EVC$ NAME BYTE, 

VALUE WORD, 

THREAD 3YTE) EXTERNAL? 
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DE CL £ R E 

SEQUENCERS BYTE EXTERNAL, 
SEQ$TABLEf 130) STRUCTURE 
( SEQ ANAME BYTE, 

SEQ$VALUE WORD) EXTERNAL; 



/*014 sic##* sic*###:!:**!}:**!!:*####*!!:#*:###*##*##*# / 

/* DECLARATION OF EXTERNAL PROCEDURE REFERENCES */ 
/* THE FILE AND MODULE WHERE THEY ARE DEFINED ARE V 
/* LISTED. */ 



INITI ALAPROC: PROCEDURE EXTERNAL? END? 

/* IN FILE: INITKK.SRC */ 

/* IN MODULE: INITAMOD */ 

AWAIT: PROCEDURE (E VC A ID .AWAITED A VALUE ) EXTERNAL? 

DECLARE EVC$ID BYTE, AWAITED$ VALUE WORD? 

fnd; 

VPSCHEDULER : PROCEDURE EXTERNAL? END? 

/* IN FILE: SCHED . ASM */ 

DECLARE INTVEC LABEL EXTERNAL? 

/* IN FILE: SCHED. ASM */ 

DECLARE INTRAVECTOR POINTER AT(0110H) I NI TI AL (0 1 NT VEC ) ? 

/* IN FILE: SCHED. ASM */ 

/*0168 x #**#****#**###**#*#*#**#*##*#****#'-**#**###* *#*#***#* / 
/* THESE DIAGNOSTIC MESSAGES MAY EVENTUALLY BE REMOVED. */ 
/* THE UTILITY PROCEDURES, HOWEVER, ARE ALSO USED BY THE */ 
/* MONITOR PROC 

DECLARE 

MSG11*) BYTE 
MSG1A( * ) BYTE 
MSG4 ( * ) BYTE 
MSG4A. ( * ) BYTE 
MSG7 ( * ) BYTE 
MSG7A ( * ) BYTE 
MS G7B ( # ) BYTE 
MSG10(*) BYTE 
MSG11 (*) BYTE 
MSG12 ( * ) BYTE 
MS G20 ( * ) BYTE 
MSG22 ( * ) BYTE 
MSG23 ( * ) 3YTE 
MSG24 ( * ) BYTE 



. THEY SHOULD NOT BE REMOVED. */ 



INITIAL ('ENTERING RET AVP ',13,10,'%'), 
INITIAL (' RUNNING$V?$INDEX = %'), 

INITIAL ('ENTERING RDYTHI SV? ',13 , 10 , '% ' ) , 
INITIAL (' SET VP TO READY: V? = %'), 

INITIAL ('ENTERING GETWOEK ' , 13 , 10 , '% ' ) , 
INITIAL (' SET VP TO RUNNING: VP = %'), 

INITIAL (' SELECTEDADBR = %'), 

INITIAL ('ENTERING IDLE$VP '.13,10,'%'), 
INITIAL ('UPDATE IDLE COUNT ',13,10,'%'), 
INITIAL ('ENTERING KERNEL $ I N IT ' , 10 , 13 , '% ' ) , 
INITIAL ('ENTERING LOCATEAEVC ',10,13,'%'), 
INITIAL ('ENTERING LOCATESSEQ ',10,13,'%'), 
INITIAL (' FOUND' ,10 ,13 , '%' ) , 

INITIAL (' NOT FOUND', 10,13, '%') ? 



DECLARE 

CR LITERALLY '0DH 
LF LITERALLY '0AH'J 

OUT $ CHAR : PROCEDURE( CHAR ) EXTERNAL.* 
DECLARE CHAR BYTE; 

end; 

OUTLINE: PROCEDURE ( LINE$?TR ) EXTERNAL; 
DECLARE LINE5PTR POINTER? 

end; 

OUT $ NUM: PROCEDURE ( NUM ) EXTERNAL.* 
DECLARE NUM BYTE; 

end; 

OUT$DNUM : PROCEDURE ( DNUM ) EXTERNAL; 
DECLARE DNUM WORD; 

end; 



OUT$HEX : PROCEDURE (B ) EXTERNAL; 
DECLARE 3 EYTEJ 

end; 



IN$CHAP : PROCEDURE ( RET$PTR ) EXTERNAL.* 
DECLARE RET$?TR POINTER; 

end; 

INiDNUM: PROCEDURE (RST$?TR) EXTERNAL; 

DECLARE RET5PTR POINTER; 

end; 



IN^NUM: PROCEDURE (RET$PTR ) EXTERNAL; 
DECLARE RETSPTR POINTER; 

end; 
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/*027 1 ######*£## ######## ###### #########*####### 7 

/* STACK TATA & I N IT IALI AZTION ?CR SYSTEM PROCESSES */ 



DECLARE IDLEiSTACK 
(SP 
BP 

RET $ TYPE 

LENGTH ( 030 H ) 

DI 

SI 

DS 

DX 

CX 

AX 

BX 

ES 

START 

FL 



STRUCTURE 
WORD , 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

WORD, 

POINTER, /* IP.CS */ 

WORD)' AT ( I DLE$STACK$ABS ) 
INITI AL( 66 H , 0 , I NT$ RETURN , 

0,0, 0,0, 0,0, 0,0, 0,2, 3 , 0,0, 0,0, 0,0, 0,0, 0,0, 0 , 3 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 IDLE$PROC , 230 H )J 



DECLARE I NIT5STACK 


STRUCTURE 


(SP 


WORD, 


BP 


WORD, 


RET$TYPE 


WORD, 


LENGTH ( 030 H) 


WORD, 


DI 


WORD, 


SI 


WORD, 


DS 


WORD, 


DX 


WORD, 


CX 


WORD, 


AX 


WORD, 


BX 


WORD, 


ES 


WORD , 


START 


POINTER, /* IP.CS */ 


FL 


WORD) AT(INIT$STACK$A 3 S ) 


INITIAL! 66H 


, 0 , I NTSRITUR N , 


0,0, 0,0, 0,0, 0,0, 0,0 


,0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 


0, 0,0,0 ,0,0, 0,0, 0,0 


,0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 


0,0, 0,0, 0,0, 0,0, 


01 NI TIAL$ PROC , 200 E ); 

/* 200 H SETS THE IF FLAG */ 
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DECLARE MCNITOR$STAC£ STRUCTURE 



SP 


WORD, 


3P 


WORD, 


RETSTYPE 


WORD, 


LENGTH (030H) 


WORD, 


DI 


WORD, 


SI 


WORD, 


DS 


WORD, 


DX 


WORD, 


C X 


WORD, 


AX 


WORD, 


BX 


WORD , 


ES 


WORD, 


START 


POINTER 



/* IP,CS */ 



FL 



WORD) AT(M0NIT0R$STACK$A3S) 
INITIAL (66H, 0, INT$RETURN , 



0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 
0,0, 0,0, 0,0, 0,0, 0MONITORSPROC, 200H)J 



/#0 35 sjt 3*5? 3*3*3*# #### 3*########## 3* 3*#### J 

/############# #3*#### ####3*# #####3* ############ #3*# ############ / 



/* ESTiTP PROCEDURE KLINEF 5-25-92 */ 

/* */ 

/* USED 3Y THE SCHEDULER TO FIND OUT WHAT IS THE CURRENT */ 
/* RUNNING PFOCESS. IT'S INDEX IN VPM IS RETURNED. */ 

/* */ 

/* CALLS MADE TO: OUT$HEX OUTSCHAR */ 



/##&#### ##3* ######## ### 3* 3*################################### / 



RETSVP : PROCEDURE BYTE REENTRANT PUBLIC,* 

DECLARE RUNNING$VP$ INDEX BYTE; 

CALL 0UT$LINE(0MSG1 ) J 

/* SEARCH THE VP MAP FOR RUNNING PROCESS INDEX */ 

DO RUNN ING$V?$I NDEX = PRDS . VP$START TO ?RDS.VP$END5 
IF VPM ( RUNNINGS V? Si NDEX ) .STATE = RUNNING 
THEN GO TO FOUND; 

END; /* D0 */ 

FOUND: 

CALL OUT$LI NE( 0MSG1 A ) ; 

CALL OUT$HEX(RUNNING$VP$INDEX ); 

CALL OUTSCHAR(CR) J 
CALL OUTSCHAR(LF) ; 

RETURN RUNNINGS VP Si NDEX J 
END; /* RETSVP PROCEDURE */ 
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/* RDYTHISVP PROCEDURE KLINEF 5-25-S2 */ 

/* */ 

/* CHANGES A VIRTUAL PROCESSOR STATE TO READY */ 

/* */ 

/* CALLS MADE TO: OUT$HEX OUT5CHAR */ 



RDYTHISVP: PROCEDURE REENTRANT PUBLIC? 



DECLARE VP BYTE? 

CALL OUT $LINE ( OMS G4 ) ? 

VP = RET$VP? 

CALL CUT$LINE( 0MSG4A ) ? 

CALL OUT$HEX(V?)? 

CALL OUT$CHAR ( CR ) ? 

CALL OUT$CHAR ( LF ) ? 

VPM(VP) .STATE = READY? 
RETURN? 

END? /* RDYTHISVP PROCEDURE */ 
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/* GETWORE PROCEDURE ELI NEF 5-25-32 */ 

/* */ 

/* DETERMINES THE NEXT ELIGI3LS VIRTUAL PROCESSOR TO RUN */ 

/* */ 

/* CALLS MALE TO: OUT$CHAR OUT$LlNE OUTSDNUM */ 

%<# %<# V; %v v*# ^ 4# %*#J# v* %b %•# »y %*# y# %t» ^ «ju %*+ ju j# u# «/# •*# u# ^ ou y# %v u# / 

f|^ #|* ^ /|^ >J» ^p» J,** ^ ^ ^|* #|% *4* # ( % # ( « #jW #|% ^ *|* ^ / 



GETWORE: PROCEDURE WORD REENTRANT PU3LIC? 

DECLARE ( PRI , N , I ) BYTE; 

DECLARE SELECTED$D3R WORD; 

DECLARE DISPLAY BYTE; 



CALL CUT$LINE(0MSG7) ; 
PRI = 255; 



DO /* SEARCH VPM FOR ELIGIBLE VIRTUAL PROCESSOR TO RUN */ 
I = PRDS . V?$ST ART TO ?RDS.V?$END; 

IF /* THIS VP'S PRIORITY IS HIGHER THAN PRI */ 

( ( VPM (I) .VP$PRIORITY <= PRI) AND 
(VPM (I ) .STATE = READY)) THEN DO; 

/* SELECT THIS VIRTUAL PROCESSOR */ 

PRI = VPM(I) .VP^PRIORITY; 

N = l; 

end; /* if */ 

END; /* DO LOOP SEARCH OF VPM */ 



/* SET SELECTED VIRTUAL PROCESSOR */ 
VPM (N). STATE = RUNNING? 

SELECTED$DBR = V?M( N ) . SS $REG ? 

CALL OUT $LI NE(0MSG7A ) ; 

CALL OUT $ HEX ( N ) > 

CALL OUT $ CHAR ( CR) J 
CALL OUT$CHAR(LF) ; 

CALL OUT^LINE(0MSG73) J 
CALL OUT$D.NUM(SELECTED$DBR) ? 

CALL OUTSCHAR(CR) ? 

CALL OUT$CEAR(LF) ? 

RETURN SELECTED$DBR; 

END; /* GETWORE PROCEDURE */ 



/#0 / 
/* LOCATE^EVC PROCEDURE KLINEE 5-25-32 */ 



/* */ 

/* FUNCTION CALL. RETURNS THE INDEX IN EVSNTCOUNT TA3LE */ 
/* OF THE EVENT NAME PASSED TO IT. */ 
/* V 



/* CALLS MADE TO: OUT$CEAR OUT$LINE */ 



LOC ATE$EVC : PROCEDURE( EVENT5NAME ) EYTE REENTRANT PUBLIC: 



DECLARE EVENT$ NAME BYTE? 

DECLARE (MATCH, EVCT3L$I NDEX ) 3YTEJ 

CALL OUT$LINE ( 0MSG20 ) J 

MATCH = FALSE? 

EVCTBL$I NDEX — 0J 

/* SEARCH DOWN THE EVSNTCOUNT TABLE TO LOCATE THE */ 

/* DESIRED EVENTCOUNT BY MATCHING THE NAMES */ 

DO WHILE (MATCH = FALSE) AND ( SVCTBL5I NDEX < EVENTS); 

/* DO WHILE HAVE NOT FOUND THE EVENTCOUNT AND HAVE NOT */ 
/* REACHED END OF THE TABLE */ 

IF EVENT$NAME = EVC $TBL ( EV CTBL $ I NDEX ) . EVC $N AME THEN 
MATCH = TRUE? 

ELSE 

EV CT3L$I NDEX = EVC TBL $1 NDSX+1 ; 
end; /* WHILE */ 

/* IF HAVE FOUND THE EVENTCOUNT */ 

IF (MATCH = TRUE) THEN DO? 

/* RETURN ITS INDEX IN THE EVC$TBL */ 

CALL OUT$LINE( 0MSG23 ) J 
RETURN EVCTBL$ INDEX; 

end; 

ELSE do; 

/* RETURN NOT FOUND CODE */ 

CALL CUT$LI NE (0MSG24 ) ; 

RETURN NOT$FOUNDJ 
end; /* ELSE ♦/ 

END; /* LOCATE$SVC PROCEDURE */ 
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/^ 060 1 *########### #*#### / 
/* L0CAT2$SEQ PROCEDURE KLINEF 5-23-32 */ 

/* */ 

/* FUNCTION CALL TO RETURN TEE INDEX OF TEE SEQUENCER */ 
/# SPECIFIED IN THE SEQ-TABLE. */ 

/* */ 

/* CALLS MADE TO: OUTLINE */ 



LOCATE$SEQ : PROCEDURE ( SEQ$NAME ) BYTE REENTRANT PUBLIC? 

DECLARE SEQ$ NAME BITS? 

DECLARE ( MATCH, SEQTBL$INDEX ) EYTE ? 

CALL OUT $ LI NE ( 0MSG22 ) ? 

MATCH = FALSE? 

SEQTBL$ I NDEX = 0? 

DO WHILE (MATCH = FALSE) AND (S EQTBL$I NDEX < SEQUENCERS)? 
IF SE05NAMS = SEO$ TABLE (SEOTBL5INDSX ) .SEQ$NAME THEN 
MATCH = TRUE? 

ELSE 

SEOTBL$I NDEX = SEOTBL$I NDEX + 1? 

END? /* WHILE */ 

IF (MATCH = TRUE) THEN DO? 

CALL OUT$LI NE ( 0MSG23 ) ? 

RETURN SEOTBL$ IN DEX ? 

END? /* IF */ 

rT CD TS A • 

CALL* CUT$LINE(0MSG24) ? 

RETURN NOT$FOUND? 

END? /* ESLE */ 

END? /* LOCATE$SEO PROCEDURE */ 
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/* 0667 **************** ******* ************* 

/ JL> <>/ «ly V* »V «</ »*/ *1^ kt «JU «'/ «'• «t« .<» tl. <1/ J« *•* J< »'* «(/ »t« *1/ *U *'# k># *1# J< J« *•» *l» »'< *•* •<* k'< JU k-V *<* «(< 

/ 3j* ■(» #,» »>* v »,« »(* »i* >p »,< «-,* n» <■(» <■(' *^» <u* ^ «■** *k* ■<t* n* v •>« »)' *i» -r *v v 'p »p 



/* SYSTEM PROCESSES 
/* 



%'/ %•# %U4»# 4<# %V %*# 4I# %•# JU WU / 

*1* ^ j4 #|4 rj\ <f|% /p «f|% / 

*/ 

*/ 



0 



/* IDLE PROCESS KLINEF 5-24-S2 */ 

*/ 

THIS PROCESS IS SCHEDULED IF ALL OTHER PROCESSES IN */ 
THE VPM ARE BLOCKED. THE STARTING ADDRESS IS PROVIDED-/ 
TO THE IDLE$S TACK AND PLACED IN PRDS . IDLESDBR . A */ 

COUNTER IS INCREMENTED ABOUT EVERY SECOND. THE COUNT */ 
IS MAINTAINED IN THE PRDS TABLE AND IS A ROUGH MEASURE*/ 
OF SYSTEM PERFORMANCE BY GIVING AN INDICATION OF THE */ 
AMOUNT OF TIME SPENT IN THE IDLE PROCESS. */ 

'TIME' */ 

*/ 

#*####### is########:*#### a*:*#### *####:*:**: s':######:}: 5* / 



/* — 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/*- 
/* 
/* 



CALLS MADE TO 



PLM86 PROCEDURE 
OUTLINE 



IDLE$ PROC : PROCEDURE REENTRANT PUBLIC? 



DECLARE I BYTE? 

CALL OUT$LINE(@MSG10 ) ? 

/* DELAYS ONE (1) SECOND */ 

LOOP: DO I = 1 TO 40? 

CALL TIME( 250 )? 

END? 

CALL OUT$LI NE( 0MSG11 ) ? 

PRDS. COUNTER = PRDS. COUNTER + 1? 
GO TO LOOP? 

END? /* I DLE^PROC */ 
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/ *@£Qg** ************************ *********** *****#**%> / 

/* MONITOR PROCESS KLINSF 5-25-82 */ 

/* */ 

/* TEE MONITOR PROCESS IS INITIALIZED BY TEE CS LIKE */ 

/* INIT AND IDLE. IT HAS TEE RESERVED ID 0? 0FEE AND A */ 
/* PRIORITY OF OH. IT IS ALWAYS BLOCKED OR WAITING UNTIL*/ 
/* IT IS PRSEMTED EY THE USER. */ 



/* 



*/ 



/* CALLS MADE TO: OUT$LINE OUT$CHAR */ 
/* OUT$DNUM I N$DNUM */ 
/* IN$ NUM */ 



MONITOR5PROC: PROCEDURE REENTRANT PUBLIC; 



DECLARE 

PTR POINTER, 

PTR2 POINTER, 

PTR3 EASED PTR2 POINTER, 

ADDR STRUCTURE (OFFSET WORD, BASE WORD), 

CONTENTS BASED PTR BYTE? 

DECLARE 

(LINECOMPLETE, L00P2) BYTE, 

(QUANTITY, COUNT) BYTE, 

(INCER, INDEX, VALID$CMD) BYTE; 

LOOP: V ALID$CMD = 0? 

CALL OUT$CEAR(CR ) J 
CALL OUT$CHAR(LF); 

CALL OUT $ CHAR ( ' . ' ) J 
DO WHILE NOT VALID$CMD; 

CALL I N$ CEAR ( 31 NCHR ) J 

IF ( INCHR = 'D ' ) OR ( INCHR = 'S') OR ( I NCHR = 'S') THEN 
VALID5CMD = OFFHJ 

IF ( I NCHR=64H ) OR (INCHR=65H) OR (INCHR=73E) THEN 
VALID$CMD = 0FFHJ 

I? VALID$CMD = 0FFH THEN CALL OUT$CHAR( INCHR) ! 
end; /* DO WHILE */ 
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IF (INCHR = 'D') OR (INCER = 64H) THEN DO? 

/* DISPLAY COMMAND SECTION */ 

CALL IN$DNUM( 0ADDR .BASE ) J 

CALL OUT$CHAR( ' : ') J 

CALL IN$DNUM(0ADDR. OFFSET); 

PTR2 = 0ADDRJ 
PTR = PTR3J 

/* CONTENTS SHOULD NOW BE SET */ 

DO WHILE (INCHROCR) AND ( INCHR023E ) » 

CALL IN$CHAP. (0INCHR) J 
END; /* DO WHILE */ 

IF INCHR = CR THEN DO; 

CALL OUT$CHAR( '-'); 

CALL OUTSNUM (CONTENTS ) ; 

CALL OUT$CEAR(CR); 

C ALL OUT$CHAR(LF) ; 

END; /* IF NORMAL 1 ADDR DISPLAY */ 

IF INCER = 23H THEN DO* 

COUNT = 0J 

CALL OUT$CHAR( '#') ; 

CALL IN$NUM ( 0QUANT ITY) ; 

DO WHILE QUANTITY > 0? 

CALL OUTS CHAR ( CR ) ; 

CALL OUTSCHAR(LF) ; 

CALL OUT$DNUM( ADDR. BASE) ; 

CALL OUTSCHAR ( ': '); 

CALL OUTSDNUM(ADDR. OFFSET); 

LINECOMPLETE = FALSE; 

DO WHILE LINECOMPLETE = FALSE; 

CALL OUTS CHAR (' '); 

CALL OUT $ NUM ( CONTENTS ) ; 

ADDR. OFFSET = ADDR. OFFSET + l; 

PTR = PTR3* 

QUANTITY = QUANTITY - 1? 

IF ( (ADDR. OFFSET AND 000FH)=0) OR 

(QUANTITY = 0) THEN L INECCM?LSTE=TRUE * 
END; /* DO WHILE LINE NOT COMPLETE */ 

END; /* DO WHILE QUANTITY */ 

END? /* IF MULTI ADDR DISPLAY */ 

END? /* DISPLAY COMMAND SECTION */ 
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IF ( I NCHR = 'S ' ) OR ( I N CHR =?3H ) THEN DO; 

/* SUBSTITUTE COMMAND SECTION */ 

CALL IN$DNUM( 0ADDR .BASE ) * 

CALL OUT$CHAR (':')? 

CALL I N$ DNUM ( 0 ADDR .OFFSET ) J 
CALL OUT$CHAR( '-'); 

PTR2 = gaddr; 

PTR = PTR3I 

/* CURRENT CONTENTS SHOULD NOW BE AVAILABLE */ 
CALL OUT$NUM( CONTENTS ) ; 

LOOP 2 = true; 

DO WHILE L00P2 = TRUE; 

DO WHILE ( INCHRO ' , ' )AND ( I NCERO ' ') 
AND(INCHROCR) J 
CALL IN$CHAR((?INCER)i 

end; 

IF ( INCHR = CR) THEN L00P2 = FALSE? 

IF (INCHR = THEN DO? 

/* SKIP THIS A DDR AND GO TO NEXT FOR SUB */ 
CALL 0UT$CHAR1 CR) ? 

CALL OUT$CHAR(LF) ; 

ADDR. OFFSET = ADDR. OFFSET + 1? 

PTR = PTR3? 

CALL OUT$DNUM( ADDR. BASE ) ? 

CALL 0UT$ CHAR ( '); 

CALL OUT$DNUM (ADDR. OFFSET ) ? 

CALL OUT $ CHAP. ( 

CALL OUT5NUM (CONTENTS ) ; 

END? /* IF SKI? FOR NEXT SU3 */ 

IF (INCHR = ' ') THEN DO * 

CALL OUT 5 CHAR ( ' ') ; 

CALL IN$NUM(0CONTENTS ) J 

DO WHILE (INCHROCR )AND( INCHRO' . '); 

CALL IN$CHAR(0INCHR) ? 

end; 

IF (INCHR = CR) THEN L00P2 = FALSE; 

IF (INCHR = THEN DO; 

CALL OUT$CEAR( ')? 

ADDR .OFFSET = ADDR. OFFSET * 1? 

PTR = PTR3; 

CALL OUT$CHAR(CR) ? 

CALL OUT$CEAR(LF); 

CALL OUT5DNUM (ADDR. BASE) J 
CALL OUT $ CHAR ( ') ? 

CALL 0UT$DNUM( ADDR. OFFSET ) ; 

CALL OUT$CHAR ( '-') ; 

CALL OUT$NUM ( CONTENTS ) ? 

END; /* IF GO TO NEXT ADDR */ 

END? /* IF CHANGE CONTENTS */ 

INCHR = 'X'? /* REINITIALIZE CMD */ 
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END; /* LOOP, CONTINUOUS SU3 CMD */ 

END; /* SUBSTITUTE COMMAND SECTION */ 

IE ( I NCHR= '!') OR (INCHR=65H) THEN DO; 

/* FIND OUT WHICH VPS IS RUNNING 'ME ' */ 
INDEX = RET$VP; 

/* NOW BLOCK MYSELF */ 

VPM(INDEX) .STATE = WAITING? 

CALL VPSCHEDULER? /* NO RETURN */ 

END? /* IF */ 

GO TC loop; 

end; /* MONITOR PROCESS */ 
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/ •&• />**, m «<• <J« «l* «A» *'* %>* »'» vU »*• »V <J< V* JU %•/ «X> *i» «y *>» **< %>• *X» »•» »»/ «.t» «v s'< >•« «A# J/ «•* «<« J< <i< J* «(< j« ju <ju «IU «Jl» J/ *ju *v / 

v 0 3 T f #l * *** ^ **' **' ^ *'' vn* v¥ # f V'p *i* *p 'i' 'Y' »>' '' *i % "T* •«' 'T' V 'i' »i» 'v' «r »t' <t* 'i» '(♦ *v #,» *v v 3JZ •»,' ■»,-> 3^C r,* ^ ~r» / 

wL* «JU y« «V «JU «JU «t# *’« «>o J« *)» «JU »i# »£» «■* «■• *'» •»■* %•/ «^> >•* V* w*> *•» »>< *># **# **# »•# »** yu «<« «a* V* »V >JU yV *v« «IU <Jf »•» «V *V yV J« *<« y> y> / 

^ *p ^ /j* *)■% ^ #f> »j» *](» «f» /p «y« ^ . yp »p ^ #.* »p *(* »p #,» #,» rjV <p *j» »,s ^j-» ?,% >|S t 



/ 



/* STARTING POINT CF THE OPERATING SYSTEM */ 

/❖ £/ 

/* ROUTINE INITIALIZES THE OS AND IS NOT REPEATED. */ 

jjt # if:#### ###:!: a*##### is####:):###### / 

/a*#:!:##;;;######## ##>>:#### ##&s£s$C!!«j!<:$C5:s:$e##:$e:jCJ$e#si: ### ###:(; sfc *###:)£ :jt ###:*:#;)< f 



/* TO INITIALIZE THE PRD5 TABLE FOR THIS CPU */ 
DECLARE CPU $PTR POINTER DATA( OPRDS . CPU $ NUMBER ) , 

ZZ byte; 



disable; 

CALL OUT $ LI NE (GMSG12 ) ; 

/* INITIALIZE P P I AND PIC*/ 

OUTPUT ( PORT ACE ) = 80HJ /* PPI CONTROL - MAKE PORT C OUTPUT */ 
OUTPUT (PORT $C0) = 13E; /* PIC - ICW1 - EDGE TRIGGERED */ 

OUTPUT ( P0RT$C2 ) = 40HJ/* PIC - ICW2 -VECTOR TABLE ADDRESS */ 
OUTPUT ( PORT $C2) = 0FHJ/* PIC - ICV4 -MCS86 MODE, AUTO EOI */ 



/* ESTABLISH UNIQUE SEQUENTIAL NUMBER FOR THIS CPU */ 
/* SET GL03ALAL0CK */ 

DO WHILE LOCKASET (0GLOBALALOCK ,1 19 ) ; END; 

PRDS . CPU $ NUMBER * CPUAINIT; 

CPUAI NIT = CPUAINIT + i; 

/* RELEASE GLOBAL LOCK */ 

GL03ALAL0CK = 0; 

/* SET UP INITIAL START AND END FOR PROC TABLE */ 
PRDS . VP$ START = 0; 

DO ZZ = 1 TO PRDS .CPUANUM3ER; 

PRDS .VPASTART = PRDS . VPAST ART + MAXAVPSACPUJ 

end; 

PRDS . V?$END = PRDS .VPASTART + 2; 

PRDS. VPS APEPACPU = 3J 

/* INITIALIZE THE VP MAP FOR IDLE AND INIT PROC */ 

/* AND MONITOR PROCESS */ 

VPM(PRDS .VPASTART ) .VPAID = 255,* 

V?M(PRDS. VPASTART) .STATE = l; 

VPM(PRDS. VPASTART) .VPAPRIORITT = 0; 

VPM (PRDS .VPASTART) .EVCATEREAD = 255; 

VPM(?RDS .VPASTART ) .EVC AAWAV ALUE = 0; 

VPM(PRDS .VPASTART) .SSAREG = I NIT AS TACKASEG ; 
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V PM (PRDS .VPiSTART+1) ,VP$ ID = 255; 

VPM1PRDS . VPSSTART+l ) .STATE = 1J 
V PM (PRDS . VP$START+1 ) ,V?$ PRIORITY = 255; 

VPM ( PRDS . VP $ START +1 ) . EV C $ THREAD = 255J 
VPM (PRDS . VPS START + 1 ) ,EVC$AW$VALUS = 0; 
V?M(PRDS.VP$START+1) ,SS$REG = IDL3$STACK$S3G J 

VPM(PRDS .VP$START+2) .VP$ID = 0PEH; 

VPM(PRDS .VP$START+2) .STATS = 7; 

VPM(?RDS . VP$START+2 ) .7?$ PRIORITY = 0J 
VPM(PRDS .VPiSTART+2) .SVC$THREAD = 255; 

V?M(PRDS .VP$START+2) . SVC SAW $V ALUS = 0; 
VPM(PRDS.VP$START+2) .SS$REG = MONITOR$STACK$SEG» 

NR$ PPS = NR $?.?S + I? 

NR$V?S (PRDS .CPU$NUMBSR ) = 3; 

HDtf$INT$FLAG( PRDS .CPU$NUMBER ) = 0 J 

enable; 



call vpsceeduler; 



/* NO RETURN */ 



END; /* Ll $MODULE */ 



/if######*#*#######)*#############*##.######*###*##*#########* / 

tf*## *«:(;:£ ########## j)c #;{e St jjc#:;!:.!:**##:*## a*#### / 

I it if. £&$’!<$$ $£ ^5 5 ^^; j|ts^ ’I 5 / 
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ISIS-II MCS-86 LCOATER, VI. 1 INVOKED BY: 
L0C86 KORE.1NK ADDRESSES ( SEGMENTS ■ & 

STACK ( 03000H) ,& 

INITMOD_CODE( 02800E) ,& 

GLOBALMODULS DATA (0E0000H) ) ) 5. 

S EGS IZE ( STACK ( 75H ) 

RS ( 0H TC 0FEEH ) Ma p 

WARNING 56: SEGMENT IN RESERVED SPACE 

SEGMENT: (NO N A M E } 

SYMBOL TABLE OF MODULE L1MODULE 
READ FROM FILE EORE.LNK 
WRITTEN TC FILE :E0:KORE 



3ASE 


OFFSET 


TYPE 


SYMBOL 


BASE 


OFFSET 


TYPE 


SYMBOL 


0240H 


00 OAR 


PUB 


PRDS 


0100B 


046 AH 


PUB 


MONI TORPROC 


0100H 


0420H 


PUB 


IDLEPRCC 


0100H 


0381H 


PUB 


LOCATES EO 


0100H 


0 2S2H 


PUB 


LOCATEEVC 


0100E 


0217H 


PUB 


GETWORK 


0100E 


01 COE 


PUB 


RDYTHIS VP 


0100E 


014 EH 


PUB 


RETVP 


0182H 


0BB5H 


PUR 


OUTHFX 


0182H 


n A30H 


PUB 


INHEX 


0182H 


0A60H 


PUB 


SENDCEAR 


0182E 


0A3DE 


PUB 


R EC V CHAR 


0182E 


0 A 1 1 H 


PUB 


OUTDNUM 


0132E 


09D P H 


PUB 


INDNUM 


0132H 


09C0H 


PUB 


OUTNUM 


0182E 


097 1H 


PUB 


OUTLINE 


01S2H 


0959* 


PUB 


OUTC^AR 


01S2E 


093 EH 


PUB 


INNUM 


0182H 


0923H 


PUB 


INCEAR 


0182E 


07DER 


PUB 


CREATEPROC 


01S2E 


0772H 


PUB 


TICKET 


0182F 


06FCH 


PU3 


CREATES EO 


0182R 


04£7 W 


PUB 


PR pfmpt 


0182 17 


0334H 


PUB 


ADVANCE 


0132H 


027FH 


PUB 


AWAIT 


0132E 


020 RH 


?U3 


READ 


0182H 


0130H 


PUB 


CPF 1 TEE7C 


01S2E 


0060H 


PUB 


GATEKEEPER 


0264H 


0000^ 


PUB 


VPSCEEDULER0264E 


003DE 


PUE 


INTVEC 


0280H 


0002E 


PUB 


INITIAL PRCC 


E000E 


0190H 


PUB 


7?M 


E000H 


04C9H 


PUB 


SEOT *BLE 


E000F 


04C8H 


?U3 


SEQUENCERS 


E000H 


04C7H 


PUB 


CPUINIT 




000 0H 


PUB 


EVCTBL 


E000H 


04C6E 


PUBEV 


ENTS 


S000H 


043CH 


PUB 


HDWINTFLAC- 


E000H 


04B2H 


pub” 


NR VPS 


E000H 


04B1H 


PUB 


NRRPS 


E000E 


04B0H 


PUB 


GLOBALLOCK 










MEMORY 


MAP OF 


MCDUL 


,E L1MCDULE 










READ FROM FILE 


: YORE 


' . LNK 










WRITTEN 


i TO FIL 


,E :F0 


!:KCRE 
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MODULI START ADDINS S PARAGRAPH = 0100H OFFSET = 0030H 
SEGMENT MAP 



START 


STOP 


LENGTH 


ALIO 


M name 


CLASS 


0S113H 


00113E 


0004E 


A 


■ ABSOLUTE ) 




01000H 


01825H 


082SE 


V 


LI MODULE CODE 


CODE 


01S26H 


02406H 


0PI3H 


V 


L2M0DULE CODE 


CODE 


0240AH 


0240AH 


0000E 


w 


GLOB AL M C PULE C 
-ODE 


CODE 


0240AH 


02S3BH 


0132E 


y 


LI v ODULE DATA 


DATA 


0253CE 


0261FE 


00E4H 


W 


L2 M 0DULS DATA 


DATA 


02620H 


0263DE 


001FE 


w 


I N I T M 0 D DATA 


DATA 


02640H 


02640E 


0^071 P 


n 


??SEG 




02640H 


026E0E 


00 A 1 H 


G 


SCEEDULER 




02800H 


02824E 


0025E 


W 


INITMOD CODE 


CODE 


03000H 


03074H 


0075H 


w 


STACK 


STACK 


03100H 


03173B 


007CE 


A 


(ABSOLUTE) 




03200H 


0327BE 


007CE 


a 


( ABSOLUTE) 




03300H 


0337BH 


007CE 


A 


(ABSOLUTE) 




E0000H 


E05F4H 


05F5H 


W 


GLCBALMODULE D 
-AT a 


DATA 


E05F6H 


E0EF6H 


00007 


V 


v-TM 0 v Y 


MEMORY 
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APPENDIX G 





SCHEDULER & INTERRUPT HANDLER SOURCE CODE 


The 


source code in this appendix is part of LEVEL I, but 


it was 


assembled under ASM86 instead of of compiled. No 


special 


attributes are required for the assembler. The 


source 


code is contained in file: SCHED.ASM. It is linked 



along with the other modules of LEVEL I and LEVEL II into 
file: KORE.LNK. Its memory map is included in the memory 
map for KORE. 
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J« %l# %JU V-* ^ JU JU V# JU %JU «U %i> %V Jy J# V*» %•# sU *X» V* <JU ^ vV JU JU V* *4* J> %t# %JU JU JU JU «L JU «U «!» v<# 

t ^ v v nr ^ ^ ^ t t* v # c wt^*t *v v -i % <r 'r t ^r t # i % t t t v ^r t 



* SCHEDULER 



ASM FILE 



KLlNEF 2-27-82 



# * 

* THE FOLLOWING ARE THE EXTERNAL PLM86 PROCEDURES CALLED * 

* BY THIS MODULE. * 



EXTRN GETWORKiFAR 
EXTRN RDYTHISVPtFAR 
EXTRN PHDS: BYTE 
EXTRN HDWINTFLAGiBYTE 
EXTRN GL03ALL0CK:BYTE 

SCHEDULER SEGMENT 



PU3LIC VPSCHEDULER 
PU3LIC INTVEC 

VPSCHEDULER PROC FAR 

ASSUME C S tSCHEDULER 
ASSUME DS : NOTHING 
ASSUME SS: NOTHING 
ASSUME ESjNOTHING 

; ENTRY POINT FOR A CALL TO SCHEDULER 



CL I 

PUSH DS 
MOV CX , 0H 



SWA? VIRTUAL PROCESSORS. THIS IS ACCOMPLISHED BY 
SAVING THE SP AND BP REGISTERS ON THE STACK, ALONG 

It l« 



WITH THE RETURN TYPE FLAG AND 
* THE SS REGISTER OR STACK SEGMS 
5 PROCESS SELECTED TO RUN NEX 

INTJOIN : MOV SSjWORD PTR 0,SP 
MOV S S : WORD PTR 2,3P 
MOV SS ‘.WORD PTR 4,CX 
CALL GETWORK 
MOV SS , AX 

? SWA? VIRTUAL PROCESSOR 
J NOW OPERATING IN NEWLY 



STTING A NEW DBR , 
T REGISTER OF THE 



5 SAVE "CURRENT" SP 
; SAVE ’CURRENT’ 3P 
; SAVE IRET_I ND FLAG 

; SS : = 'SELECTED ’ SS_REG 

CONTEXT COMPLETE AT THIS POINT 
SELECTED PROCESS STACK 
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MOV SP,SS:WORD PTR 0 ; S?:= .! SELECTED SP 

MOV BP ,SS : WORD PTR 2 ; 3?:= SELECTED B? 

MOV CX,SS :WORD PTR 4 

; CHECK TOR RETURN TYPE, NORMAL OR INTERRUPT 

CMP CX.77H 
JZ I NT RET 

NORM_RET : POP DS 

J UNLOCK GLOBALSLOCK 
MOV AX, SEC GLOB ALLOCS 
MOV ES , AX 
MOV ES rGLOBALLOCK ,0 

STI 

RET 

VPSCHEDULER ENDP 

; fc# a*####*: a*########## Sc# a*## 



* INTERRUPT HANDLER * 



INTERRU?T_HANDLER PROC NEAR 

ASSUME CS rSCEEDULER 
ASSUME DS :NOTHING 
ASSUME SS: NOTHING 
ASSUME ES :NOTHI NG 



INTVEC: CLI 

PUSH ES J SAVE NEEDED REGs TO TEST INTERRUPT FLAG 
PUSH BX 
PUSH AX 
PUSH CX 

CALL HA.RDWARE_ INT FLAG 
MOV AL , 0 

XCHG AL.ES :HDVINTFLAG[BX] 

CMP AL , 77H ; IS INT FLAG ON ? 

JZ PUSH REST REGS i IF 'YES ' SAVE REST REGs 
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POP cx 
POP AX 

POP BX 
POP ES 

STI 
IRET 

PUSH_REST_RFGS : PUSH DX J FLAG WAS ON SO NEED 
PUSH DS i PE-SECHEDULE 

PUSH SI 
PUSH DI 

MOV A.X.SSG GLOB ALLOCS 
MOV ES, AX 

CK: MOV AL.119 J LOCK GL03AL LOCK 

LOCK XCHG ES :GLOBALLOCK , AL 
TEST AL, AL 
JNZ CK 



; IF 'NOT' RESUME PREVIOUS 
J EXECUTION POINT 



CALL RDYTHIS VP 

MOV CX ,??H ; JUMP TO SCHEDULER 

JMP I NT JO I N 



IN TRET: POP DI 



POP 


si ; 


RETURN FOR 


POP 


DS 


PROCESS WHICH 


POP 


dx ; 


HAD PREVIOUSLY 


POP 


cx ; 

; UNLOCK GLOBAL$ LOCK 


BEEN INTERRUPTED 


MOV 


AX , SEG GL03ALL0CK 




MOV 


ES, AX 




MOV 


ES :GLO3ALLOCK,0 




POP 


AX 




POP 


BX 




POP 

STI 


ES 




IRET 


\ 





INTERRUPT_HANDLER ENDP 

- ##### *##**##:*# si:#####*# ##### ####### 5?=?## ## 
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* # # # # # # # 35c # * # # # # 3jc * a{C * £# JJS # ## # #* 

* HARDWARE INTERRUPT FLAG 

* 



# # # # ^C # # # # £ # # # # sjc # sfc # # v # # # # # # Jjs # SjS 






HARDWARE_INT_ELAG PROC NEAR 

ASSUME CS -.SCHEDULER 
ASSUME DS : NOTHING 
ASSUME SS: NOTHING 
ASSUME ES : NOTHING 



HDW EL 


AG: MOV 


AX.SEG PRDS 




MOV 


ES, AX 






MOV 


BX , 0H 






MOV 


CL , ES : 


PHDS [BX] 


5GET CPU * 


MOV 


CH.0 




RETURN IN BX 


MOV 


BX , CX 






MOV 


AX. SEC 


HDW INTEL AG 


JSET UP HDV$ I NT iE LAG 


MOV 


ES, AX 




; SEGMENT 


RET 






? RETURN IN ES REG 



HARDWARE_ INT_FLAG ENDP 
SCHEDULER ENDS 

END 
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APPENDIX H 



GLOBAL DATA BASE AMD INITIAL PROCESS CODE 

Two files are presented here: GLOBAL. SRC and INITK.SRC. 
They are both separately compiled with the LARGE attribute. 
They are linked into the file: KORE.LNK. They are 
represented in the memory map for KORE located at the end of 
Appendix E. INITK reserves only the minimum amount of space 
required by operating system for the initial process. The 
user's initial process may be larger. The user may have to 
explicitly reserve more space in the LOC86 command. See the 
file: LOCP.CSD for an example. If you look at the XORE 
memory map at the end of Appendix F, you will see that the 
INITMOD CODE segment is only 25H bytes long. 



136 



f ## ### ## # Si*#### # # ## 5}J3$S ## iji # 5jS # 5^ # £ 5*C # # # 5$C # 5jC 5jt j£ # jjfi # # # £ # # # # ## # # # # # # # J 

/#0009^**^*^***^^*^^*^**********#^***^***^ :, * i: * : ' c5 ' i3!?5ic;1;a ' :5 ’ ;2t:5 ' c / 
/* FILE: GLOBAL. SRC 

VERSION: KLI NEE 5-25-82 

PROCEDURES 

DEFINED: NONE 



REMARKS :THIS MODULE CONTAINS DECLARATIONS FOR ALL THE 
GLOBAL DATA THAT RESIDES IN SHARED COMMON 
MEMORY. IT'S LOCATED THERE BY THE LOCATE COM- 
MAND AND BY SPECIFYING THAT THE 
GLOBAL$MODULE_DATA SEGMENT BE LOCATED AT SOME 
ABSOLUTE ADDRESS. 

*/ 



GL03AL$M0D(JLE: DO J 

J #£####*:£#########£###❖#£###*#*###*######################## / 

/* THE FOLLOWING THREE LITERAL DECLARATIONS ARE ALSO */ 

/* GIVEN IN TEE LEVSL1 & LEVEL2 MODULES OF THE OPERATING */ 
/* SYSTEM. A CHANGE HERE WOULD HAVE TO BE REFLECTED IN */ 
/* THOSE MODULES ALSO. */ 



Pi V P T & wTP 

MAX5CPU LITERALLY '10'. 

MAX$VPS $CPU LITERALLY '10', 

MAX$C?U$$A$MAX$VPS$C?U LITERALLY '100'; 



DECLARE 

GLOBAL$LCCK 3YTE PUBLIC INITIAL (0 ) ; 



/* THIS SHOULD REFLECT THE MAX$CPU ABOVE */ 

DECLARE 

NR$RPS BYTE PUBLIC INITIALS), 

NR$ VPS ( MAX $ CPU ) BYTE PUBLIC 

INITIAL (0 ,0,0, 0,0,0 ,0 ,0,0,0)? 

DECLARE HDW$INT$?LAG(MAX$CPU) BYTE PU3LICJ 



DECLARE EVENTS BYTE PUBLIC INITIAL(l); 

DECLARE EVC STBL ( 100 ) STRUCTURE 
( EVCS NAME BYTE, 

VALUE WORD, 

THREAD BYTE) PUBLIC 

INI TI A L ( 0FEH ,0,255); 

/* EVC 'FE' IS RESERVED FOR THE OP SYS */ 
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DECLARE CPUS I N I T BYTE PUELIC INITIALS); 

DECLARE SECUENCERS BYTE PUBLIC lJJITIAL(0)» 



DECLARE 



SEO$TABLE(100) 

(SE05NAME 

SEOSVALUE 



STRUCTURE 

BYTE, 

W CRD ) public; 



DECLARE 



VPM ( MAX$CPUA$$$MAXAVPS$CPU ) STRUCTURE 



( VP$ID BYTE, 

VPSSTATE BYTE, 

VPiPRIORITY BYTE, 

EVCSTHREAD BYTE, 

EVC$AV$VALUE WORD, 



SS $REG 



WORD) public; 



END; /* MODULE */ 



/ # # # # # # 3$C 3*C # # # 3* # 3$C # # JjC # # # # # # # # 3$C 3}S # # # # # # # J$C # # # 3jC # # 3$S # # 3£ # # # # 3je 5$C # # 3* 



/* INITK MODULE KLINEF 5-27-82*/ 

/* */ 

/* THE CODE SEGMENT 0 E THIS MODULE IS WHAT RESERVES SPACE */ 
/* BY THE OS FOR THE USER INITIAL PROCESS. THIS IS */ 

/* EXECUTABLE IN IT'S OWN RIGHT. THUS IE THE USER DOES */ 

/* NOT PROVIDE AN INITIAL PROCESS THIS ONE WILL EXECUTE, */ 

/* BLOCK ITSELF, AND IDLE THE CPU. THE ADDRESS OF THE */ 

/* INITIAL CODE SEGMENT IS PROVIDED TO LEVEL1 AND IT IS */ 

/* REFLECTED IN THE PLM LOCATE COMMAND. THE ADDRESSES */ 

/* PROVIDED MUST AGREE. THIS PROCESS HAS THE HIGHEST #/ 

/* PRIORITY AND WILL ALWAYS BE SCHEDULED FIRST BY THE */ 



/* SCHEDULER. */ 

/* */ 

/* CALLS MADE TO: AWAIT */ 



/*#£##£###£ ###))[#:>;:# JjCJjtJJCSje# JjtJjt a*#*###;*##;*#*:** a*#***#### / 



IN IT$MOD : DC? 

DECLARE 

MSG13 ( * ) BYTE INITIAL(10, 'ENTERING INITIAL PROCESS ', 

13,10,'%')? 

OUTLINE: PROCEDURE ( PTR ) EXTERNAL? 

DECLARE PTR POINTER? 

END? 



AWAIT: PROCEDURE ( NAME, VALUE ) EXTERNAL? 

DECLARE NAME BYTE, VALUE WORD? 

end; 



IN ITI AL$?ROC : PROCEDURE PUBLIC? 
DECLARE I BYTE? 



/* AFTER INITIALIZATION THIS PROCESS BLOCKS #/ 
/* ITSELF TO ALLOW THE NEWLY CREATED PROCESSES */ 
/* TO BE SCHEDULED. */ 
/* THIS AREA SHOULD 3E WRITTEN OVER BY USER INIT */ 
/* PROCEDURE MODULE. */ 



CALL OUT$LI NE( 0MSG13 ) ? 

CALL AWAIT ( 0FEH , 1); 

END? /* INITIAL$PR0C */ 
END? /* I NIT$MOD */ 
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APPENDIX I 





USER GATE MODULE SOURCE CODE 


This 


source code is contained in file: GATE. SRC. It is 


compiled 


with the attribute LARGE. The object code file: 



GATE. OBJ is given to the user to link with his initial 
process and user processes. 

1 40 



/* #*##*******####*#*#%#** X^##***#*******#*****#####***# / 



/* SATE MODULE FILE 'GATE. SRC' KLINNEF 5-26-32 */ 

/* V 

/* THIS MODULE IS GIVEN TO THE USER IN OBJ FORM TO LINK */ 
/* WITH HIS INITIAL AND PROCESS MODULES. ANY CHANGES TO */ 
/* USER SERVICES AVAILABLE FROM TEE OS HAVE TO BE */ 

/* REFLECTED HERE. IN THIS WAY THE USER DOES NOT HAVE TO*/ 
/* BE CONCERNED WITH ACTUAL GATEKEEPER SERVICES CODES. */ 

/* */ 

/* ALL CALLS ARE MADE TO THE GATEKEEPER IN LEVEL2 OF TEE */ 
/* CS. THE ADDRESS OF THE GATEKEEPER MUST BE GIVEN BELOW.*/ 



/* 00 18 ****************** ***’******** *************** ********* / 



GATE$MCD : DO; 

/* REFLECT GATEKEEPER ADDRESS HERE. GKl=OFFSET , GK2=3ASE */ 
DECLARE (GK1.GK2) WORD DATA (0060H , 0182H ) , 

GAT E$ KEEPER POINTER AT(GGKl)? 

DECLARE RETS WORD, 

RETS $PTR POINTER DATA ( GRETS ) ? 

7*0029***************************************************** / 



AWAIT: PROCEDURE ( NAME, COUNT ) PUBLIC? 

DECLARE NAME BYTE, COUNT WORD? 

CALL GATE$KEEPER ( 0, NAME, COUNT, 0, 0); 

return; 

end; /* await */ 

/*0037***** ************************************************ / 

ADVANCE: PROCEDURE! NAME ) PUBLIC? 

DECLARE NAME 3YTE? 

CALL GATE$KSE?ER ( 1, NAME, 0, 0, 0 )? 

RETURN? 

end; /* ADVANCE */ 

/# 00 4 5## ##*###### Sc###########:**!*########:*##:*###:*## Jr#######* / 

CREATE$EVC : PROCEDURE! NAME ) PUBLIC? 

DECLARE NAME BYTE? 

CALL GATESKEEPER! 2, NAME, 0, 0. 0 ); 

RETURN? 

END? /* CREATE $E VC */ 
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/*007 5 *# ######£*#**#########❖####*########*##**#*# ########* / 



CREATE-SEQ: ?ROCEDURE( NAME ) PUBLIC > 

DECLARE NAME BYTE', 

CALL GATE-KEEPER ( 3, NAME, 0, 0, 0 )? 

return; 

end; /* CREATE$SEO */ 

/*0081 ******************************************** ********* / 



TICKET: PROCEDURE ( NAME ) WORD PUBLIC; 

DECLARE NAME BYTE; 

CALL GATESKEEPER ( 4, NAME, 0, RETSSPTR ); 

RETURN RETS? 
end; /* TICKET */ 

/* 008 9 ***** *************************************** ********* / 

READ: PROCEDURE ( NAME ) WORD PUBLIC? 

DECLARE NAME BYTE? 

CALL GATE-KEEPER ( 5, NAME, 0, RETS-PTR )? 

RETURN RETS? 

END? /* READ */ 

/* 0 09 7 ******************************************** ********* / 
CREATE-PROC: PROCEDURE ( PRCC-ID, PROC-PRI , PROC-STACK-LOC , 

proc-ip, peoc-cs ) public; 

DECLARE ( PROCSID, PROC-PRI ) BYTE, 

(PROC-STACK-LOC, PROC-IP, PEOC-CS ) WORD? 

DECLARE PROCSTABLE STRUCTURE 
(PROCSID BYTE, 

PROC-PRI BYTE, 

PRO C- STACK -S EG WORD, 

PROC-IP WORD, 

PROC-CS word); 

DECLARE PROC-PTR POINTER DATA (0PR0C-TA3LE ) J 

PROC-TABLE . PROC-I D = PROC-ID? 

PROC-TABLE. PROC-PRI = PROC-PRI? 

PROC-TABLE. PROC-STACK-SEG = PROC-STACK-LOC / 10E? 
PROCSTABLE. PROC-I? = PROC$IP; 

PROC-TABLE. PROC-CS = PRCC-CS? 

CALL GATESKFE?ER{ 6 . 0, 0 , PROC-PTR )? 

RETURN? 

end; /* CREATE-PROC */ 
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OUTSCHAR: PROCEDURE! CHAR ) PUELIC; 
DECLARE CHAR BYTE ? 

CALL GATE-KEEPER ( 9, CHAR, 0, 0, 0)? 

return; 

end; 



OUT$LI NE : PROCEDURS( LINE$PTR ) PUBLIC? 
DECLARE LI NE-PTR POINTER? 

/* LINE MUST END WITH '%' */ 

/* AND BE LESS THAN 80 CHAR */ 
CALL GATE-KEEPER ( 9, 0, 0, LINE-PTR); 
RETURN? 

end; 



OUT-NUM: PROCEDURE( NUM ) PUBLIC? /** NUM IS BYTE **/ 
DECLARE NUM BYTE? 

CALL GATE-KEEPER ( 10, NUM, 0, 0, 0 )? 

return; 

end; 



/*Q1Q5*****************Z *********************************** / 

OUT-DNUM: PROCEDURE! DNUM ) PUBLIC? /** DNUM IS WORD **/ 
DECLARE DNUM WORD? /** DOUBLE BYTE **/ 

CALL GATE-KEEPER ( 11, 0, DNUM, 0,0); 

RETURN? 

end; 



PRE-EMPT: PROCEDURE! PROC$ID ) PUBLIC? 
DECLARE PROC- ID BYTE? 

CALL GATE-KEEPER! 7, PROC-ID, 0, 0, 0 )? 
RETURN? 

END; /* PREEMPT */ 






IN -CHAR : PROCEDURE (RET$PTR) PUBLIC? 

DECLARE RET-PTR POINTER; 

CALL GATEKEEPER !12 , 0. 0, RET -PTR ) ? 

end; 



143 



IN $NUM : PROCEDURE ( RET$PTR ) PUBLIC; 

DECLARE RET$PTR POINTER 5 

CALL GATEKEEPER (13, 0, 0, RETSPTR); 

end; 

/s)!021 2 = S e5 # :s:e5 ^ esSel * S5i:s!e5;£ ^ C5 ^ =!s: * :?J:s:es>:s: ' , * e sI'9!s^»!«5! i 59:=5es}isSss{ e 5! e 5 | )is}=5{e5S>!<=!s3!=^s!=s}E50:JJ : s5«»5i^5{s5! s 3>:5^’i t =>:s! l =5^= ! )e / 

IN$DNUM: PROCEDURE ( RET $PTE ) PUBLIC? 

DECLARE RET$PTR POINTER; 

CALL GATEKEEPER (14, 0, 0, RET $?TR ) ; 

end; 

y 3*: #### #3fc 3fc ## 3fc £####### #3fc #### Jjc### # 3}: 3}:3j: 3}: #######:£ #3}:# #:$C3}:i{S3{t y 

END? /* GATE$MOD */ 

/3*##3fc#3£#3fc#3£ ##3fc3fc#3fc:fc#3£3fcj£:fc#;}c##3{:3}::$:3^3£ 3*:# 3* ## 3*c 3* 3£ #3$: # 35:3;; ^3}: 3}c # ##3}: 5}: / 

/ # 3}; 3J; 3{C X* 3jc # 3{C 3}: 3^ 3^ # 3}: # # 3jc # # # J{C# # # # 3{C 3(C 3(1 # * 3^ ^ 3^ # 3(< # * # # # *C # * # 3^ # 3^ 3$: # 3*S # 3J: 5jC ^ # 3}: # # 3$C / 

############ 3^3^ S^SjfSjC £3£ >£#### JfJCjJ:### S^SjSlfc# ^ 
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APPENDIX J 



USER PROCESSES I 

This appendix has three parts. It contains the source 
code for one of the user initial processes, INIT1.SRC. The 
source code in file, PR0C1.SRC, is provided. They are 
separately compiled with the LARGE attribute. They are 
linked into P01.LNK and the memory map from file, P01.MP2, 
is provided. The executable code file P01 is loaded onto 
one of the SBC's. 
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/ X X X X X X X X X X X X X X X X X X X X 

t ¥ v # r> vn % -r o'^r n' v ¥ 

/* INITIAL PP.OCESSS 



X %U X X X X X X %U x *v X X X X X X X X X X X X % V X X X X V# X X X 

^Mr vtt w¥ -v* v ¥ k* ¥ ^ v -r o %- r ir¥ v¥ ¥ ¥ ¥ ¥ # r ^r 1 ¥ 



p-i 



KLINEF 5-27-82 



/ 

/ 



/* V 

/* the code segment of this module will be ovsrlayed on */ 

/* A segment reserved by the os. this initial process */ 



/* WILL CREATE ALL THE PROCESS THAT WILL RESIDE ON A REAL*/ 
/* PROCESSOR. ALL CALL TO CREATS$PROCESS MUST BE MADE */ 



/* FOR EACH PROCESS. */ 

/* */ 



/* CALLS MADE TO: CREATE$?ROC S. AWAIT(T0 BLOCK INIT) */ 

afsaf:## aje ###>* ##a):aft a£ ^c-csjc# jfcaf:# 3^ / 



INI T$ MODULE: DO; 

CREATE$?ROC : PROCEDURE ( ?R0C$ID, PRCC$?RI, 

PROC $S TACK ALOC , ?ROC$IP, PROC$CS ) EXTERNAL? 

DECLARE ( PR0C$ID , PROC$PRI ) EYTE, 

( PR OCi STACKS LOC , ?R0C$IP, PROCACS) *ORD; 

end; 

AWAIT: PROCEDURE! EVC$ID, VALUE ) EXTERNAL? 

DECLARE EVC$ID BYTE, 

VALUE WORD? 

END? 

INIT: PROCEDURE PUBLIC? 

jjc s{c ######## a*:### # / 

/* * * * USER AREA OF RESPONSIBILITY #***#*/ 

/* MUST MAKE CALL FOR EACH PROCESS TO BE CREATED. USER */ 
/* PROVIDES ALL PARAMETERS. */ 

^#a£#£###:!t3{c:£#3fc#a{caj«:##a|:3{:## ## ######### #a;ofc##a5ca£# a£a;s#:{:a£ a^a^cajojtafcaisais^: / 



CALL CREATEiPROC ( 1, 253, 7000H, 06H, 720H )? 



/###£# Jit############ at#### afca):# afr ajaajeafc a£# ais## a*#*# ajaaiea^ai:# y,; # ;’,s * a;c ### a;<#a}:a& / 

/* * * * END OF USFR RESPONSIBLE! * * * */ 

a£ #######:£ ## jit####)* a^sjaa.'cajtafc# ##:£:}: #a(< sic### i£a}c>jcj£sj< j£a*a>: a* :£a£ / 

/* THIS STATEMENT BLOCKS THIS PROCESS AND ALLOWS */ 

/* THE NEWLY CREATED PROCESSES TO BE SCHEDULED. */ 

CALL AWAIT! 0FEH , 1 )? 

END? /* PROCEDURE */ 

END; /* MODULE */ 
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/ye##########################*#*###########*:#########*###### / 

/########## ##*#*###*## *#***#*####**#*#**##*###*#*###***##*# / 
/* PARAMETERS: 

PP.OC$ ID : (BYTE) DESIRED ID EOR PROCESS. 'EE' IS RESERVED. 

PROC$PRI: (BYTE) DESIRED PRIORITY. HIGH IS 0. 

LOW IS 255. 

PROC$STACK$LOC: (WORD) ABSOLUTE ADDRESS OF STACK. MUST HAVE 
ACCESS TO 120H BYTES OF FREE SPACE. 

USER PROCESS MUST BE CODED IN PROCEDURE BLOCK. 
THE OS PROVIDES STACK OF 110H BYTES. 

PROC5IP: (WORD) USER PROCESS STARTING ADDRESS OFFSET. 

PROC$ CS : (WORD ) USER PROCESS STARTING ADDRESS 3ASE . */ 
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/ %t* Ju WU ^ J/ «V ^ O# %t» %c %*-» %l# %U Jf %u v^ ^ *V 4# Uf V # %l ? %V Jf V* ^ ^ %^# %v %*«• ^ v# ^ / 

#p #p ?|W ^ #p ?p #^i ^|% ?p #p #p #p ?p ^ ^ #(% #p #p >p #p ^ v ^ ^ v ^r ^ v ^ >r* 'r -v ^ v nr v nr ^ v n" nr # r or or or ^ or or nr v o % ? r / 



PROCESS 1 MODULE 



KLINSF 6-1-S2 



/* 

^ ______________ 

/* THIS IS 3ASSD ON THE ORIGINAL DEMONSTRATION THAT COX 

/* RAN. 

/* 

/* IMPORTANT! AFTER LINKING AND LOCATING THIS MODULE, 

/* THE A3 SO LUTE ADDRESS OF THE PROCEDURE BLOCK LABEL , 

/* 'PI' MUST SS REFLECTED IN THE INITIAL PROCESS IN FILS' 
/* INIT1.SRC 

/£ I*####:* sje#s;«##:4e *££!*# a****####;**#####:!::**#: 



/ 
-v 
*/ 
*/ 
*/ 

*/ 
s / 

*/ 

*/ 
!* / 



CSUPP$MODULS : DO; 

DECLARE I WORD? 

DECLARE CP LITERALLY '0DE ' , 

LF LITERALLY '0AH '» 



DECLARE K WORD. 

DECLARE CSUP? BYTE DATA (33); 

DECLARE FLDES BYTE DATA ( 44 ) 5 
DECLARE NEW BYTE DATA‘99H)J 

jjt# ### ## a*##### ### ###*£;;£){!#*## 3)5 a*# / 

DECLARE 

MSGl(-) BYTE INITIAL ( 'PROC #1. INITIAL ENTRY INTO', 
'CLUTTER SUPPRESSION', 10, 13 , '%' ) , 

MSG2(*) BYTE I NI TI AL ( 'PROC #1. WAIT FOR DATA READY', 
10,13,'%'), 

MSG3 ( * ) BYTE IN I T I AL ( 'PROC #1. PERFORMING CLUTTER', 

' SUPPRESSION: FRAME » %'), 

MSG4(*) BYTE IN I T IAL ' PROC #1 . ADVANCE FILTER ', 
'DESIGN EVENT COUNT ' ,10, 13 , '% ' ) , 

MSG5(*) BYTE IN ITIAL ( 'PROC #1. CALLED READ TWICE.', 

' RETURNED: %'), 

MSG6(*) 3YTE IN ITIAL (' PROC #1. CALLED TICKET', 

' TWICE. SECOND VALUE RETURNED: %'), 

MSG7(*) BYTE IN ITIAL (10,13, 



148 






AWAIT: PROCEDURE ( EVC5ID , AW AITED$ VALUE) EXTERNAL; 
DECLARE EVC$ ID BITE, 

*WAITED$ VALUE WORD* 

end; 

ADVANCE: PROCEDURE ! EVCil D ) EXTERNAL; 

DECLARE EVC$ ID BYTE? 

end; 

CREATS^EVC: PRCCEDURE( NAME ) EXTERNAL; 

DECLARE NAME BYTE; 

end; 

CREATE$SEO: PROCEDURE! NAME ) EXTERNAL? 

DECLARE NAME BYTE? 

end; 

TICKET: PROCEDURE! NAME ) WORD EXTERNAL? 

DECLARE NAME BYTE; 

END? 



READ: PROCEDURE! NAME ) WORD EXTERNAL? 

DECLARE NAME BYTE? 

end; 

OUT$CHAR : PROCEDURE ( CHAR ) EXTERNAL? 
DECLARE CHAR BYTE; 

end; 

OUT$NUM : PROCEDURE! NUM ) EXTERNAL? 

DECLARE NUM BYTE? 

END? 

CUT5DNUM : PROCEDURE! DNUM ) EXTERNAL? 
DECLARE DNUM WORD? 

end; 



OUT$LI NE : PROCEDURE! LINE$PTR ) EXTERNAL? 

DECLARE LINE$PT? POINTER? 

END? 
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/ JL <JU «!• */U «JU J< «k> «J» X X X X X X X X X »)/ X X X X X 
/ ^n» v*r •v t* "i* *r* *r *r* »i» 'V* ■v *i* * t k *r v i* *r 'r'r 

PI: PROCEDURE PUBLIC J 

CALL 0UT$LINE(@MSG1 ) ; 

/* CREATE SYNCHRONIZATION PRIMITIVES */ 
CALL CREATE$EVC ( CSUPP ) »’ 

CALL CREATE$EVC (FLDES ) ; 

/* CALL READ AS A TEST */ 

K = READ ( CSUPP); 

CALL OUT $LI NE ( 0MSG5 ); 

CALL OUT$DNUM( K )J 
CALL OUT$LINE(0MSG7 ) ; 

/* CREATE SEQUENCER PRIMITIVES */ 

CALL CREATE$SEQ(NEV) ; 

/* CALL TICKET TWICE AS A TEST */ 

K = TICKET (NEW); 

K = TICKET ( NEW ) J 

CALL 0UT$LI.NE(0MSG6) ; 

CALL OUTSDNUM ( K ); 

CALL 0UT$LINE(@MSG7 ) ; 

/* PROCESS 1 LOOP BEGINS HERE 



i = 1; 

DO WHILE (I <= 0EEF7H); 

CALL 0UT$LINE(GMSG2) ; 

CALL AWAIT ( CSUPP ,1)5 
I = I + 1; /* <======== */ 

CALL OUT$LINE(0MSG3) ; 

CALL OUT$DNUM{ I) ; 

CALL OUT$LINE(0MSG7) ; 

DO K = 0 TO 1000 ; 

CALL TIME (250); 

end; 



CALL OUT$LI NE( 0MSGA ) ; 

CALL ADVANCE (FLEES ) ; 

end; /* WHILE */ 
end; /* pi */ 

END; /* MODULE */ 
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ISIS-II M CS -?6 LC CATER , VI. 1 INVOKED • 
L0C86 ?0 1 . LNX A DD'~S S ES ( SEGM ENTS ( E 
INITMODULE COEE''02800H) ,5, 
CSU??MCDULl_CCDF'07200H> ,& 

CSU??MCDULE_DATA( 0750CH ' ,S 
GATEMOD_CCD B( 077*0*1 ,S 
GATE M OD_DATA. ' 079E0H ) ,& 

STACX(070.e0E) ) )£ 

SEGSI ZE( STACK ( 1 00H ) )& 

RS ( 0 TC 27EFH) 



SYMBOL TABLE OF MODULE INITMODULE 



READ FROM FI L 7 


’ P01. 


INK 




WRI PTEN 


TC FILE :F0 


:?01 




3 AS E 


OFFSET 


TYP 7 


SYMBOL 


3 5 S F 


3220H 


0002H 


PUB 


INIT 


0720H 


0770H 


022LF 


PUR 


INTNUM 


0770H 


0770H 


01E3- 


PUB 


I NCSA 7 


07? 0H 


0770H 


0 1 Ac H 


PUB 


CUTDNUM 


0770H 


0770H 


0 1 64 H 


PUB 


OUTLINE 


0770* 


07705 


00F4H 


PUB 


CREATEPROC 


0770 * 


0770H 


009CH 


?U3 


TICKET 


0770H 


0770H 


0056H 


PUB 


CPE 4 TEEVC 


7 770R 


0770H 


000EH 


PUB 


AWAIT 




MEMORY 


MAP OF 


MCEUL 


,E IN ITMODUL 7 




READ FROM FILE 


1 P01. 


LMK 




WRITTEN 


i TO FIL 


.E :F0 


: P01 





SEGMENT MAP 



START 


STOP 


02800H 


02630H 


02S32H 


02S32H 


07000H 

07200H 


07 OFF H 
0732DH 


07500H 


0761CH 


07700H 
07SE0H 
07 9 E AH 


0794DH 

079ESF 

079E7H 



LENGTH ALIGN N S MF 

003 IP V 

0000H W 

0100H W 
012EE ¥ 

011 EH V 

024EH W 
000 AH W 

0000H V 



OFFSET 


TYPE 


SYMBOL 


0006H 


PUB 


?1 


020CH 


PUB 


INNUM 


01C8H 


PUB 


PREEMPT 


0185H 


PUE 


CUTNUM 


0141H 


PUB 


CUT CHAR 


00C8E 


PUB 


READ 


307SH 


PUB 


CREATES 


0033H 


PUB 


ADVANCE 



CLASS 



I NIT M ODULE CCD 


CODE 


-V 


INITMODULE DAT 


DATA 


-A 


STACK 


STACK 


CSUPPMODULE CO 


CODE 


-DF 


CSUPPMODULE DA 


DATA 


-T a 


GATEMOD CODE 


CODE 


GATE M OD DATA 


DATA 


MEMORY 


MEMORY 
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APPENDIX K 



USER PROCESSES II 

This appendix has three parts. It contains the source 
code for one of the user initial processes, INIT2.SRC. The 
source code for user processes in files, PR0C2.SRC, 
PR0C3-SRC, and PR0C5-SRC is provided. They are all linked 
into file, P02.LNK. The executable code file, P02 is loaded 
onto one of the SBC's. The memory map in file, P02.MP2, is 
also provided . 
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! # # 3 js # # sjs # s*s ## 3 }: j£ ## # # 3 {t :;c # 3^^: # 3 js # # 3 $: # s{c ajs :£ 3 js 3 £ # 

/* INITIAL PROCESS P-2,3,5 



KLINEF 6-1,82 */ 



/* */ 

/* TEE COBS SEGMENT OF THIS MODULE WILL 3E OVERLAYED ON */ 
/* A SEGMENT RESERVED 5Y TEE OS. THIS INITIAL PROCESS */ 
/* WILL CREATE ALL THE PROCESSES THAT WILL RESIDE ON A */ 
/* REAL PROCESSOR. ALL CALLS TO CRSATE$?ROCSS S MUST 3E */ 
/* MADE FOR EACH PROCESS. */ 



/# * y 

/* CALLS MADE TO: CREATE$?ROC S. AWAIT(TO BLOCK INIT) */ 

y########## # #a|s:£j‘£;{Ci{e:*sj}::i>:5j:£ J-5# aft## y 



INI T$MODULE : DO; 

CREATE$?ROC : PROCEDURE ( PROC$ID, PROC$PRI, 

PROC$STACK$LOC , PROC^IP, PROCiCS ) EXTERNAL* 

DECLARE ( PROC $ ID , PROC$?RI ) BYTE. 

( PR OC$ STACK $LOC , ?ROC$IP, PROC$CS) WORD; 

END; 

AWAIT: PROCEDURE! EVC$ID, VALUE ) EXTERNAL* 

DECLARE EVC $ ID BYTE, 

VALUE word; 

end; 



INIT: PROCEDURE PUBLIC; 



y 

/* * * * USER AREA OF RESPONSIBILITY * * * * * #/ 

/* MUST MAKE CALL FOR EACH PROCESS TO BE CREATED. USER */ 
/* PROVIDES ALL PARAMETERS. */ 



J 3{S 3^ 3^£ 3p 3f? 3^£ 3^ 3yC 3{C 2^2 2^2 «$£ 3^ 3|C 3^S 3^C 2^2 Jjfq* nC3*C if* *r^ n* 3 t 2 3{c 3{C 3{c jJS J^C 2{C 



2^ "i'f. # :|c ;;c 3|c sjssjc 2J: / 



CALL CREATE SPROC ( 2, 245, 7000H, 04H, 720H ); 
CALL CREATF$PROC ( 3, 253, 9000H, 04H, 920H ); 
CALL CREATE$?ROC ( 5, 254, 8000H, 06E, 820H )J 



/ # # # # # # 3{s 3jc 3 }: s*t :£ sjc sjc s$c 3^c sjc s{c sjc # :£ jjc # 3 * # 3jc # # y,c sj: 3 ^ # *c s£ 3{c 3 }: # # # # s}; # # jjc 3£ ^ 

/* - * * END OF USER RES PONS IELI TY * * 

3<c 5fr 5*C 5jc 3|c 34 c 3js $$ ## ## 

/* THIS STATEMENT 3L0CKS THIS PROCESS AND ALLOWS 
/* THE NEWLY CREATED PROCESSES TO 3S SCHEDULED. 

CALL AWAIT! 0FEH , 1 )J 

END? /* PROCEDURE */ 

END; /* MODULE */ 



# 5 * a*## 5 * a**:*## y 

u. O# / 

*T» *T* / 

sjs 3*s :’r $ s|c 3l< # Jjc 3^ f 



*/ 

*/ 
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;Jc jjc^s ## ##?,** 5)c # #5*c##5£:fc3$ej£:*;:£# ^c y 

y # # # # # j£ # £ # # y,i # >*c :Jc # # £ #?Jc # # j|s sjs :|: 5jt # 5 ;: sjs ;|: # # 5 ;: 5',? # 5js ;J: ;Js ?;c # # # sfc ?I' ?’,: # # # # # :!? 5js J 

/* PARAMETERS : 



?R 0 C $ I D : (BYTE) DESIRED ID EOR PROCESS. '?!' IS RESERVED. 

?ROC$PRI: (BYTE) DESIRED PRIORITY. HIGH IS 0. 

LOW IS 255. 

?ROC$STACK$LOC: (WORD) ABSOLUTS ADDRESS OF STACK. MUST HAVE 
ACCESS TO 1 20H BYTES OF FREE SPACE. 

USER PROCESS MUST BE CODED IN PROCEDURE BLOCK. 
THE OS PROVIDES STACK OF 110H BYTES. 

PROCAIP: (WORD) USER PROCESS STARTING ADDRESS OFFSET. 

PROC$CS : (WORD) USER PROCESS STARTING ADDRESS BASE. */ 
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/#### ### # 3jt 3}t # # 3£ # # # # #3? # # # # # # # # #:£#:£# # ##;£:£# 3jC^C^C ### / 

/* PROCESS 2 MODULE KLINSF 6-2-82 */ 

/*- 
/♦ 

/* 

/* 

/* 

/* 

/* 

/* 



— */ 
-V 
*/ 
*/ 
*/ 
*/ 

FILE:-/ 

*/ 



THIS 

RAN. 



IS BASED ON THE ORIGINAL DEMONSTRATION THAT 



IMPORTANT! ONCE THIS MODULE IS LINKED AND LOCATED, 
THE ABSOLUTE ADDRESS OF THE PROCEDURE BLOCK LABEL, 
'P02' MUST BE REFLECTED IN THE INITIAL PROCESS IN 
INIT2.SRC 



^^C3{C^34s^:^:^3jC^C3jC3^3jC^:^e3{t35C3{C^C^^:4:3{sXC^3{S5{C3^5jS3{5a{C3{S^3^3{S3{S5*:5}:s^3^^!^S^cXC3i:^4:^S3^^5}S^:3^3}C3jC^;^C^C^; / 



FLDES ^MODULE : DO? 

DECLARE I WORD; 

DECLARE Z BYTE; 

DECLARE CSUPP BYTE DATA (33); 

DECLARE FLDES BYTE DATA (44); 

## ### $ Jits}::**!###* a*#### ####*#**#*###**#*!}£ :>}:*:{! a**!####**# / 

DECLARE 

MSG1(*) BYTE INITIAL! 'PROC #2. INITIAL ENTRY INTO', 

' FILTER DESIGN ',13,10, '%') , 

MSG2( *) BYTE I NI TI AL ( 'PROC #2. WAIT FOR DATA READY', 
13 ,10, '% ' ) 

MSG3(*) BYTE INI TI AL ( 'PROC #2. PERFORMING FILTER ', 
'DESIGN ON FRA M E * %') , 

MSG4 ( * ) BYTE I NI TI AL ( 'PROC #2. ADVANCE CLUTTER ', 
'SUPPRESSION EVENT COUNT' , 10 , 13 , '% ' ) . 

• MSG5 ( * ) BYTE I NI TI AL ( 10 , 13 , '% ' ) ; 

AWAIT: PROCEDURE ( EVC$I D , AW A IT EDS VALUE ) EXTERNAL; 

DECLARE EVC$ ID BYTE, 

AW A I TED $? ALUS WORD: 

end; 

ADVANCE: PROCEDURE ( EVC $ I D ) EXTERNAL; 

DECLARE EVC A ID BYTE; 

end; 

CREATS$EVC: PROCEDURE ( NAME ) EXTERNAL? 

DECLARE NAME BYTE; 

end; 

OUT$LINE : ?ROCEDURE( PTR ) EXTERNAL? 

DECLARE PTR POINTER? 

end; 
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OUT$DNUM : PROCEDURE (DN DM) EXTERNAL; 

DECLARE DNUM WORD; 

end; 

f ####### j 

P2 ; PROCEDURE PUBLIC? 

CALL OUT$LINE(OMSGl ) ; 

/* CREATE THE SYNCHRONIZATION PRIMITIVES */ 

CALL CREATES EVC (CSUPP ) » 

CALL CREATEAEVC ( ELDES ) ? 

/* BEGIN PROCESS 2 LOOP HERE */ 

I = 0? 

DO WHILE (I <= 0FEFFH); 

CALL OUT$LINE(0MSG2) ? 

CALL AWAIT( FLDES , I ) » 

1 = 1 + 1 ? 

CALL OUT$LINE( GMSG3 ) ? 

CALL OUTSDNUM(I); 

CALL OUT$LINE(0MSG5) J 

DO Z = 0 TO 100? 

CALL TIME(250); 

end; 



CALL OUT$LINEOMSG4) ? 

CALL ADVANCE( CSUPP); 

end; /* WHILE */ 
end; /* ?2 */ 
end; /^module */ 
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/* PROCESS 3 MODULE KLINE? 6 - 2-82 #/ 

/#— — — — — — — — # / 

/* IMPORTANT! ONCE THIS MODULE IS LINKED AND LOCATED, */ 
/* THE ABSOLUTE ADDRESS OF THE PROCEDURE BLOCK LABEL, */ 

/* 'P03' MUST BE REFLECTED IN THE INITIAL PROCESS IN FILE:-/ 
/* INIT2.SRC. */ 

/ 

FLDSS3$M0DULS: DO J 



DECLARE I WORD; 

DECLARE CR LITERALLY '0DH ' , 

LF LITERALLY '0 AH ' » 
DECLARE Z BYTE; 

DECLARE FLDES BYTE DATA ( 44 ) ; 



/ i J# V* Vf %■# «JU U# «u gu u# ^ %V ^ %V V* JU %V %V J# v# JU J# ^#%V vU %** Uf %U %V «JU u# / 

/ ^ ^ ^ ^ ^ ^ ^ v ^ nr # rni' n % v ^ nr nr ^ ♦r # r n* v ^ nr nr **i % ^r ^r t ^r v ^r -nr* ^r / 



D v C L -A RE 

MSG1(*) BYTE I NI TI AL ( 'PROC #3. INITIAL ENTRY', 

' INTO FILTER DESIGN PART 2 ' ,10,13 , '% ' ) , 

MSG2(*) BYTE I NI TI AL ( '?R0C #3. WAIT FOR DATA', 

' R'S’ADY ',10,13 '% ' ) , 

MSG3(*T BYTE INITIAL! 'PROC #3. PERFORMING PART 2', 
' FILTER DESIGN ON FRAME # %'), 

MSG4 ( * ) BYTE I NI TI AL ( 10 , 13 , '% ' ) ; 

AWAIT: PROCEDURE ( EVC$I D , AWAITED$ VALUE ) EXTERNAL; 

DECLARE EVC$ID BYTE, 

AWAITED$VALUE WORD? 

end; 



ADVANCE: PROCEDURE (EVC $1 D) EXTERNAL; 
DECLARE E7 C $ I D BYTE; 

end; 

CREATE$EVC: ?R0CEDURE( NAME ) EXTERNAL; 

DECLARE NAME BYTE * 

END. 

0UT5LINE: PROCEDURE! PTR ) EXTERNAL; 
DECLARE PTR POINTER » 

end; 



OUT5DNUM: PROCEDURE ( DNUM ) EXTERNAL; 
DECLARE DNUM WORD? 

end; 
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/####### #########;?######## ############ ############/ 



P3 : PROCEDURE PUBLIC; 
CALL OUT$LINS(0MSG1 ) ; 



/* CREATE THE SYNCHRONIZATION PRIMITIVES */ 



CALL CREATSSEVC ( FLDES ) ; 

/ # # # # # Sie # * # 4: 5)£ # £ # £ $ # * * £ * $ * * # # 5?S # 5{S # * # # # SJS * # 

/* PROCESS 3 LOOP BEGINS HERE 



*<* 
T* 'l' 



"f n* n** n- - 






#sjc 



*/ 

V 



i = i; 

DO WHILE (I <= 0FFFFH); 
CALL OUTALI NE ( 0MSG2 ) J 



CALL AWAIT ( FLDES , I ) » 

I = I + i; 

CALL 0UT$LINE(0MSG3) ; 
CALL OUT$DNUM ( I ) ; 

CALL OUT$LINE(OMSG4) ; 

DO Z = 0 TO 50; 

CALL TIMS (250 ) J 

end; 

end; /* WHILE */ 
end; /* P3 */ 

END; /-MODULE */ 
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/ # 5^ # # # # # # # jjs $ * # * 

/* PR.OCES S 5 



*< # sjs ## #* >* # 5;:# 

MODULE 



«JU «JU «)« OU *•* »‘o yu ’!*!' yt* »V> «V V# «<« yu v#* yU yl* **> «U «JL> «// *-V *•» yV ^ »•< «** »*# *A* »)< / 

n» »r »r »r *rn» ¥ ¥ ¥ *r v *r ¥ ¥ *i» *r 'r v v ^ v *r ¥ t v *r *r n* v 'r / 

KLINSF 6-2-S2 */ 



/* */ 

/* THIS PROCESS ACCOMPLISHES TESTS OE THE OPERATING- SYSTEM*/ 
/* NOT YET DONE. ALL OF THE NEWLY ADDED INPUT SERVICES */ 
/* WILL BE TESTED HERE BEFORE THE PROCESS GOES INTO IT'S */ 
/* LOOP. THIS INCLUDES PREEMT. */ 
/* THIS PROCESS ACTS ON DATA LOCATED IN A BUFFER IN */ 
/* SHARED C OMM M ON MEMORY. PROCESS 4 , RESIDENT IN SOME */ 
/* OTHER CPU, WILL OUTPUT THE DATA AFTER IT HAS 3EFN PRO- */ 
/* CESSED. TEE EFFECT WILL BE E7IDENT ON THE SCREEN IF */ 
/* THEY COORDINATE CORRECTLY. */ 
/* */ 
/# IMPORTANT! AFTER LINKING AND LOCATING THIS MODULE, */ 
/* MAKE SURE THE ABSOLUTE ADDRESS OF THE PROCEDURE BLOCK */ 
/* LABEL, 'P05 ' , HAS BEEN REELECTED IN THE INITIAL PRO- */ 
/* CESS IN FILE INIT2.WRK */ 
/##*##%####*##**###### ****#*#**###******#****** *#*#**#****# / 



PROC5AMODULE: DO? 



DECLARE 

I 

FOREVER 

MONITOR 

INCHR 

WCRDAVALUE 
BYTEA VALUE 
GLOBAL A BUFFER (70 ) 
LOCALABUFFER (70) 
PR0C4A5AEVC1 
PR0C4A 5AEVC2 



BYTE, K WORD, 

LI TERALLY '0FFH ' , 
LITERALLY '0FEH ' , 
BYTE . 

WORD, 

BYTE . 

BYTE AT • 0 E0700K ) , 
BYTE , 

BYTE INITI AL ( 10H) , 
BYTE INITIAL (11H) J 






DE CL£ HE 

MSGl ( * ) BYTE I NITIAL( 'PROC #5. INITIAL ENTRY* ' ) , 

MSG2 ( * ) BYTE I NIT I AL ( 10 , 13 , 'PROC *5. PROCESSING DATA', 

' IN SHARED BUFFER% ' ) , 

MSG3 ( * ) BYTE I NITI AL( 10 , 13 , 'PROC #5. FINISHED PROCESS', 
'ING',13,10,'*') , 

MSG4 ( * ) BYTE I NIT IAL ( 10 , 13 , 'DC YOU WANT TO PREEMPT THE', 
' MONITOR ( Y OR N )?%' ) , 

MSG9 ( * ) BYTE I N IT IAL ( 10 , 13 , '% ' ) 5 

AWAIT: PROCEDURE (EV CA ID, AW AIT ED A VALUE) EXTERNAL; 

DECLARE EVCAID BYTE, AWAITED* VALUE BYTE i 

end; 
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ADVANCE: PROCEDURE ( SV C S ID ) EXTERNAL.* 

DECLARE EVCSID BYTE; 

end; 

CFEATESEVC: PROCEDURE ( NAME ) EXTERNAL? 

DECLARE NAME BYTE? 

end; 

CREATESSEQ: PROCEDURE ( NAME ) EXTERNAL? 

DECLARE NAME BYTE? 

end; 

OUT$CHAP : PROCEDURE ( CHA S ) EXTERNAL? 

DECLARE CHAR BYTE? 

END? 

IN $CHAR : PROCEDURE ( RET$PTR ) EXTERNAL? 

DECLARE RETSPTR POINTER? 

END? 

PREEMPT: PROCEDURE ( VP $1 D ) EXTERNAL? 

DECLARE VP$ID BYTE? 

END? 

OUTSLINE: PROCEDURE ( PTR ) EXTERNAL? 

DECLARE PTR POINTER? 

END? 

IN SNUM : PROCEDURE (RETSPTR) EXTERNAL? 

DECLARE RETSPTR POINTER? 

END? 

INSDNUM: PROCEDURE ( RETS PTR ) EXTERNAL? 

DECLARE RETS PTR POINTER? 

END? 

OUTSDNUM: PROCEDURE (WORDS ) EXTERNAL? 

DECLARE WORDS WORD? 

END? 

OUTSNUM: PROCEDURE ( BYT ) EXTERNAL? 

DECLARE BYT BYTE? 

END? 
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### ### #5|e WsfcsisJ?########## / 

P5 : PROCEDURE PUBLIC? 

CALL OUTSLINE ( OMSGl ) ? 

CALL CFEATE$EVC(PR0C4^5$EVC1) ? 

CALL CREATE$EVC (PR0C4$5$EVC2) ? 

DO I = 0 TO 69? 

GLOBAL*BUFFER( I ) = '.'? 

END? 

GLOBAL$3UFFER(0) = 'X'? 

K = 0? 

/ :js jje# >* ### *:fc jjc### ### sjcjjt sjc >Js s*:}:# jjcjjsjp*##### #5(5 # J 

/* PROCESS 5 LOOP BEGINS HERE */ 

DO WHILE FOREVER? 

CALL AW A I T ( PRO C4 $ 5 $ E V C 1 , K ) ? 

I? K = 35 THEN CALL PREEMPT ( MONITOR) ? 

K = K + 1? 

CALL OUT$LINZ(0MSG2) ? 

DO I = 0 TO 69? 

LOCAL$BUFFER(I) = GL03AL$BUFFE?.( I ) ? 

END? 

I = 0? 

DO WHILE LOC AL $B r JFFER ( I ) <> 'X'? 

1=1+1? 

END? 

IF I = 69 THEN LOC AL $BUFFSR( 0 ) = 'X ' ? 

ELSE LCCAL$BUFFER ( I + 1) = 'X'? 

LOCAL$BUFFER ( I ) = '.'? 

DO I = 0 TO 69? 

GLOBAL$BUFFER (I ) = LOCAL$BUFFEP.{ I ) ? 

END? 

CALL OUT^LI NE ( 0MSG3 ) ? 

CALL ADVANCE (PR0C455SEVC2) ? 

END? /* DC FOREVER */ 

END? /* P5 */ 

END? /* PR0C5$M0DULE */ 
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ISIS-II MCS-86 LOCATOR. VI .1 INVOKED BY: 
LCCS6 P02.LNK ADDRESSES SEGMENTS (& 

INI TMCDULE CODE ( 728005 ) 

FLDESMCDULE_CODE( ,& 

FLDESMCDULE_DATA ' 075005 ) 

GATEMOD_CODE( 0770 0H) .& 

GATEMOD_DAT A ( 079E05 ) 

PR0C5M0DULE_CCPE' 0=2005) ,& 

PR0C5M0DULE_D T 5 ( 08500H 1 ,& 
FLDZS3MODULE_CODE(39200^) ,& 
FLDZS3M0DULE_DATA (095005) ,& 

STACK ( 073005 ) ) )S 
SEGSI ZE( STACK ( 100H ' )& 

RS ( 0 TO 27FFH) 

SYMBOL TABLE OF MODULE I NI TMCDULE 
READ FROM FILE P02.LNK 
WRITTEN TO FILE :F0:?02 



BASE 


OFFSET 


TYPE 


SYMBOL 


BASE 


OFFSET 


TYPE 


SYMBOL 


32805 


00025 


PUB 


I NIT 


07205 


00045 


PUB 


P2 


0920E 


00045 


PUR 


?3 


082.35 


0006H 


PU3 


P5 


0770E 


0 22DF 


PUR 


INDNUM 


0^705 


720CH 


PUR 


INNUM 


0770E 


01S3E 


PUR 


IN CHAR 


07705 


31C8H 


PUB 


PREEMPT 


0770H 


01 ASH 


PUR 


OUTPNUM 


07705 


0185H 


PUB 


OUTNUM 


0770H 


3164H 


PUB 


OUTLINE 


37^05 


01415 


PUB 


OUTCHAR 


07705 


00E4H 


PUR 


CRSATEPROC 


07705 


00CSH 


PUB 


READ 


0770H 


00SCH 


PUR 


TICKET 




007SH 


PUR 


CREATESEC 


3770H 


00565 


PUB 


CREATESVC 


07705 


3 0335 


PUB 


advance 


0770H 


000EH 


PUB 


AWAIT 











MEMORY MAP OF MODULF IN ITMODULF 
READ FROM FILE P02.LNK 
WRITTEN TO FILE :F0:?02 



162 



SEGMENT MAP 



START 


STOP 


LENGTH 


ALIGN 


NAME 


CLASS 


02300H 


0235F5 


005FH 


W 


I MI TMODULE COD 

— r 


CODE 


02360H 


02360E 


0000E 


V 


JLi 

INI T v ODULE_DAT 

— A 


DATA 


07000H 


07DFF* 1 


0100H 


W 


STACK 


STACK 


07200E 


07235E 


0036H 


V 


ELDESMODULE CO 


CODE 


07500H 


07 5o5H 


00P6H 


w 


-DF 

ELDESMODULE DA 


DATA 


07700H 


0794DH 


024FH 


V 


-TA 

G 4 TEMOD CODE 


CODE 


079E0H 


079E9H 


000 AH 


w 


GAT E v OB DATA 


DATA 


S8200H 


03341 H 


0142E 


w 


PRCC5MCDULE CO 


CODE 


06500H 


0S5S8H 


03E7H 


w 


-DE 

?PCC5M0DULE_DA 

— T i 


DATA 


09200H 


09296E 


0097E 


w 


1 a 

FLDES 3 MODULE C 


CODE 


0S500H 


0953F3 


0090E 


w 


-ODF 

7LDES3 MODULE _D 

_ { TJ 

(A? SOLUTE) 
MEMORY 


DATA 


E0700H 

S0746H 


E0745E 

S0746H 


0046H 

0300E 


A 

w 


MEMORY 
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APPENDIX L 



USER PROCESSES III 

This appendix has three parts. It contai 
code for one of the user initial processes, 
source code for user processes in file, 



provided . 


They are 


all linked 


into file 


executable 


code file, 


P03 is loaded 


onto one 


The memory 


map in file 


, P03-MP2, is 


also prov 



ns the source 
INIT3 • SRC . The 
PR0C4.SRC, is 
, P03-LNK. The 
of the SBC ' s . 
ided . 
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/* IMITIAL PROCESSS P-4 KLINE? 5-27-82 */ 

/* */ 

/* THE CODE SEGMENT OF THIS MODULE WILL BE OVERLAYED ON */ 
/* A SEGMENT RESERVED BY THE OS. THIS INITIAL PROCESS */ 
/* WILL CREATE ALL THE PROCESS THAT WILL RESIDE ON A REAL*/ 
/* PROCESSOR. ALL CALL TO CREATE$PROCESS MUST BE MADS */ 



/* FOR EACH PROCESS. */ 

/# * / 



/* CALLS MADE TO: CREATE$P?.OC S AWAIT(TO BLOCK INIT) */ 

INI T$MODULE : DO; 

CREATESPROC: PROCEDURE ( PROC$ID, PROC$PRI, 

PROC $S TACK $LOC , PROCSIP, ?ROC$CS ) EXTERNAL; 

DECLARE ( PROC $ ID , PROC 5 PR I ) BYTE, 

( PROC$ ST ACK$ LOC , PROCSIP, PROC$CS) WORD; 

end; 

AWAIT: PROCEDURE ( EVC $ID , VALUE ) EXTERNAL; 

DECLARE EVC$ ID BYTE, 

VALUE word; 

end; 

INIT: PROCEDURE PUBLIC ; 

/# ####### it################################################# / 

/* * * * USER AREA OF RESPONSIBILITY * * * * * */ 

/* MUST MAKE CALL FOR EACH PROCESS TO 3E CREATED. USSR */ 
/* PROVIDES ALL PARAMETERS. */ 

5* jjca* ## I*### Jit### jjs JJ: :}::£:}£ / 



CALL CREATE^PRCC (4, 5, 7000H, 06H, 0720H )J 



/* * * * END OF USER RES PONS 1 3L ITY * * * */ 

:>::(£ jit#########################:*# / 

/* THIS STATEMENT BLOCKS THIS PROCESS AND ALLOWS */ 

/* THE NEWLY CREATED PROCESSES TO BE SCHEDULED. */ 

CALL AWAIT ( 0FEH, 1 )J 

END? /* PROCEDURE */ 

END? /* MODULE */ 
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/ kV JU *<* *J + »•< JU »!/ »'* k * k*« «>< «J/ «>< «!• k*k »•» *•» %•* k*k »•* »•» k<# kV *Jf »•* kV *'» kV »•» *>* klk »<# kV k*k %>< kV *•* k f* **< klk kA* kl# kV »•< kV kJk *•» k*k kAk JU J« k#k / 

»r w»r 'r»'r *ir *r v V v<r ¥ *i s ¥n* V n* v v ?»« v ^ Jp v v v ■v •v ^ 'i' 'i* v»r *r v v V -r- «^5 v*r vn'vn* v'T ? ?'« , 'r / 

/* PARAMETERS: 



PROC$ IP : (BYTE) DESIRED ID FOR PROCESS. 'FS ' IS RESERVED. 

PROC$ PRI : (BYTE) DESIRED PRIORITY. HIGH IS 0. 

LOW IS 255. 

?R0C$STACKALCC : (WORD) ABSOLUTE ADDRESS OF STACK. MUST HAVE 
ACCESS TO 120H BYTES OF FREE SPACE. 

USER PROCESS MUST BE CODED IN PROCEDURE BLOCK. 
THE OS PROVIDES STACK OF 110H BYTES. 

PR0C$IP: (WORD) USER PROCESS STARTING ADDRESS OFFSET. 

?R0C$ CS : (WORD) USSR PROCESS STARTING ADDRESS BASS. */ 

/ .*. v'» kik klk J» kA* k*k kJk k*k vU J, kAk J. J> kW Jf klf Vf kV J/ kV k»k «U k*k ^ \W> *•» JU k*. k*k k*k k*k ^ k*k klk kAk kV k*k kAk J« kAk kA. Jk k*k J' J» kAk k>f > %* / 
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5ic^s^^?js^^3tt5lc^:3{sa{s^5?:5jc^^3;c3}! ^3tC^i^5^5jC5^^5?^3^3^^^3?^^^:^5jC5^^5jS5?:^5tC^S^3^^5^3j:^^5jC f 

/* PROCESS 4 MODULE KLINEF 6-2-82 */ 

/* */ 

/* IMPORTANT! AFTER LINKING AND LOCATING THIS MODULE, */ 
/* MAKE SURE TEE ABSOLUTE ADDRESS OF THE PROCEDURE BLOCK */ 
/* LABEL, 'P05', HAS BEEN REFLECTED IN THE INITIAL PRC- */ 
/* CESS IN FILE INIT2.WRK */ 

#5$: ##5{« # #35: # ##3}:# # j 



PRCC4 $MODULE : DO? 

DECLARE 

(I,J) BYTE, K WORD, 

FOREVER LITERALLY '0FFH ' , 

GLOBAL$BUFFER (70) BYTE AT (0E0700H), 

LOCAL5EUFFER (70) BYTE, 

PR0C4$5$EVC1 3YTS INITIAL (10H), 

?R0C4$5$E7C2 BYTE INITIAL (11H); 

^ ^C^S3}:3{:^C^3{!3{C5!S3^3{C3{S3^^C3^3{:^:X«^C3j«^3{:3}:3;«3jC3jC3j:^C3iS^^:5{t^3{S3iC3^3^3{tS{C^^:^^3}:3}:5t:3{:3^^C3}:3iS3^^C3{C^:3jC3^^C J 



DEC LA RE 

MS G9 ( * ) BYTE INITIAL( 10,13, '% ' ) ? 

/ j« «jy v# Jf «x> %a# yu «jy *&* y« y, J* «jy <ju yy yu y* J* yy *u y* J# y# *•< y* y« y* *•» *u J# y* yy «/u y* «y yu y# y« y# yy *v y* *•# *’< y« >y y« yy y« »*# y< yu »u y, ,u / 

I *y »y» <y> «y*» v y> v y> y* yS y» y* JjS yp y* ^ y» y» y* y» *(» y* y» y» y> y» y y» y, y» ^ y* *p y» y* y« y( y* yj* y* y» y* y» y> yS y« yC y* y« y» y» ys y» y« / 



AWAIT: PROCEDURE ( EVC$ ID , A WAI TED $VALUE ) EXTERNAL? 

DECLARE EVC$ID BYTE, AW AITED$ VALUE BYTE? 

end; 

ADVANCE: ?ROCSDURE(EVC$ID) EXTERNAL? 

DECLARE EVC $ ID BYTE? 

END? 



CREATE$EV C : PROCEDURE { NAME ) EXTERNAL? 

DECLARE NAME BYTE? 

END? 

OUT ACHAR : PROCEDURE ( CHAP. ) EXTERNAL? 

DECLARE CHAR BYTE? 

END? 



OUTLINE: PROCEDURE (PTR) EXTERNAL? 

DECLARE PTR POINTER? 

END? 
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/ J# *V ^ J4 VU JU J# «|# %*# Jf JU «C* %l# %V %l» O# %U %♦/ %•# <J# %l# O# %U J# JU Of O# O/ J# %l# •*# J# JL« «l# Of O# O# Of OU Of O# 0 «» Of / 

f|% V ^ v ^ ♦p V T «Y* V V V Op #p #p v '1* *l % ' % 'TP *1^ v 'I* O' ^P *Y* O' *1* *1* O' v O' O' O' O' O' V 'p o' O' O' # i' O' 'p o' O' *P O' O' O' O' / 



P4 : PROCEDURE PUBLIC? 

CALL CRSATE5EVC(PR0C4$5$EVC1) ; 

CALL CRSATE$EVC(?R0C4$5$EVC2) 5 

## ####### #5js 2jc#5js# ##### / 

/* PROCESS 5 LOOP BEGINS HERE */ 

K = 0001 h; 

DO WHILE P0REVER5 

CALL AWAIT ( PR0C4$5$EVC2 ,X) 5 
K = K + I? 

DO I = 0 TO 69? 

LOCAL$BUFFER(I ) = GL03AL$BUFFE?.( I ) »* 

end; 

DO I = 0 TO 69? 

CALL 0UT$CHAR ( LOC ALSBUFFER ( I ) ) ; 

end; 

CALL 0UTtLINE(0MSG9) J 
DO I = 0 TO 255? 

CALL TIME (250)J 

end; 

CALL AD VANCE ( PR0C4$5$EVC 1 ) ; 

END; /* DO FOREVER */ 

END; /* P4 */ 

END; /* ?R0C4$M0DULS */ 
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ISIS-II MCS-96 10 CATER , Vl.l INVOKED 3Y: 
L0C86 P03.LNK ADDRESSES ( SEGMENTS ( & 
INITMODULS CODE ( 02S00B ) , & 
?R0C4MCDULE_CCDE ( 7220E ) ,& 

PB0C4M0DULE DAT A ( 7500H ) ,& 

STACK (7000HJ) )& 

SEGS IZE(STACK(100H) )& 

?S(0 TO 71FFH ) 

WARNING 56: SEGMENT IN RESERVED SPACE 

SEGMENT: I NITMODULE_CODE 

WARNING 56: SEGMENT IN RESERVED SPACE 

SEGMENT: STACK 

SYMBOL TABLE C? MODULE INITMODULS 
READ FROM FILE PC3.LNK 
WRITTEN TO FILE :F0:?03 



BASE 


OFFSET TYPE 


SYMBOL 




BASE OFFSET 


TYPE SYMBOL 


0280H 


0002H PUB 


I NIT 




0720E 0006H 


PUB ?4 


0755B 


022DH PUB 


INDNUM 




0755H 020CE 


PUE INNUM 


0755E 


01E3E PUB 


INCEAR 




0755E 01C8E 


PUB PREEMPT 


0755H 


01 ABE PUB 


OUTDNUM 




0755E 0185E 


PUB OUTNUM 


0755E 


0164E PUB 


OUTLINE 




0755H 0141H 


PUB CUTCEAR 


0755H 


00F4E PUB 


CREATE? 


ROC 


0755H 00C8E 


PUB READ 


0755E 


009CE PUB 


TICKET 




07553 0079E 


?U3 CRSATSSEO 


0755E 

0755H 


0056E PUB 
000EE PUB 


CREATEEVC 

AWAIT 


0755E 0033E 


PU3 ADVANCE 


MEMORY MAP OF MODUL 
READ FROM FILE ?03. 
WRITTEN TO FILE : F0 

SEGMENT MAP 


iE INITMODUL 
LNK 
: P03 


E 




START 


STOP 


LENGTE 


ALIG 


N NAME 


CLASS 


02800E 


02830E 


Z031E 


W 


INITMODULE COD 


• CODE 


07000H 


070FFH 


0100E 


W 


STACK 


STACK 


07200E 


072C2E 


00C3E 


w 


PROC4MODULE CO 
-DE 

INITMODULS DAT 

-A 

GATEMOD DATA 


CODE 


072C4E 


072C4E 


00 00E 


w 


DATA 


072C4S 


072CDE 


000AH 


w 


DATA 


07500E 


0754EE 


004FE 


w 


PR0C4M0DULS_DA 
-T A 

GATEMOD CODS 


DATA 


07550H 


0773DH 


024EE 


w 


CODE 


E0700E 


E0745B 


0046E 


A 


(ABSOLUTE) 




E0746E 


E0746E 


0000E 


w 


MEMORY 


MEMORY 
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